Web Security Solutions

• What is . NET Framework security ?

  The. NET Framework provides a user and code security model that allows you to limit the actions that users and code can perform. To program role-based security and code access security, you can use types from the system.security namespace. The. NET Framework also provides System.Security.Cryptography namespaces, exposing symmetric and asymmetric encryption and decryption, hashing, random number generation, digital signature support, and more.

  To understand the basic settings for. NET Framework security, see the. NET Security Essentials unit.

• How to write secure managed code

  The assembly is digitally signed with a strong name so that they cannot be arbitrarily altered. Also, when using strong-named Assemblies and ASP. NET, you need to be aware of the strong name issue. By adhering to robust object-oriented design principles, reduce the attack surface of your assembly, and then use code access security to further restrict which code can call your code. Use structured exception handling to prevent sensitive information from spreading beyond the current trust boundary and to develop more reliable code. Avoid general problems, especially when entering filenames and URLs.

  For information about how to improve the security of managed code, see the "Building Secure Assemblies" unit. For more information about how to use code access security effectively to further improve security, see the Code Access Security Practices Unit. For information on performing managed code review, see the Security Code Review unit.

• How to handle exceptions in a safe manner

  Do not display details about internal systems or applications, such as stack traces, SQL statement fragments, and so on. Ensure that such information is not allowed to spread beyond the end user or the current trust boundary.

  Fail safely in an exception event to ensure that the application denies access and is not stuck in an insecure state. Do not log sensitive or private data, such as passwords, to avoid damage. When an exception is logged or reported, if the user's input is included in the exception message, it is validated or cleaned. For example, if you return an HTML error message, you should encode the output to avoid script injection.

  For more information, see the "Exception Management" section of the "Building Secure Assemblies" and "Building Secure ASP. NET pages and controls" unit two.

• How to perform security review of managed code

  Use analysis tools such as FXCOP to analyze binary assemblies to ensure they are compliant. NETFramework Design Guidelines. Fix all security flaws identified by the analysis tool. Use the Text Search tool to scan the source code library for hard-coded secrets, such as passwords. Then, review the specific application elements, including Web pages and controls, data access code, Web services, service components, and so on. Pay particular attention to SQL injection and cross-site scripting flaws.

  Also review the use of sensitive code access security techniques, such as link declarations and assertions. For more information, see the "Code Review" unit.

• How to ensure the security of the developer workstation

  You can use a set of methods to ensure workstation security. Keep your accounts, protocols, ports, services, shares, files and directories, and the registry secure. Most importantly, keep your workstation current with the latest patches and updates. If you are running Internet Information Services (IIS) on Microsoft Windows_ XP or Windows 2000, run IISLockdown. IISLockdown applies a secure IIS configuration and installs the URLScan Internet Security Application Programming Interface (ISAPI) filter, which is used to detect and reject potentially malicious HTTP requests. For example, you might want to modify the configuration of the default URLScan so that you can debug your WEB application during development and testing.

  For more information, see "How to make a developer workstation secure" in the "How to" section of this guide.

• How to work with code access security and ASP

  With the. NET Framework version 1.1, you can set the trust level for ASP. Machine.config or Web. config. These trust levels use code access security to restrict the resources that an ASP. NET application can access, such as the file system, the registry, the network, the database, and so on. In addition, they provide application isolation.

  For more information about using code access security from ASP., developing a partial-trust Web application, and sandboxed privileged code, see the "Using Code access Security in ASP." Cell.

  For more information about the basics of code access security, see the Code Access Security Practices Unit.

  For more information about code access security issues to consider when developing managed code, see the section "Code Access Security Considerations" for building Secure service components, building Secure WEB services, Building Secure remote components, and building secure data access units.

• How to write code with the least permissions

  You can restrict what the code can do, regardless of the account that is used to run the code. By configuring policies or how to write code, you can use code access security to limit the resources and operations that your code allows access to. If your code does not need to access a resource or perform some sensitive action, such as calling unmanaged code, you can use declarative security attributes to ensure that your code is not granted this permission by an administrator.

  For more information, see the Code Access Security Practices Unit.

• How to restrict files I/O

  You can use code access security to limit the ability of an assembly to access the file system region and perform I/O. For example, you can restrict a Web application so that it can perform file I/O only in its virtual directory hierarchy. You can also restrict file I/O to a specific directory. This can be accomplished by programming or configuring Code access security Policy.

  For more information, see "File I/O" in the Code access security Practices Unit and "Media Trust" in the "Use Code access Security in ASP." Unit. For more information about configuring code access security Policy, see "How to use CAS policy to constrain assemblies."

• How to prevent SQL injected

  Parameterized stored procedures that use data access. Use parameters to ensure that the type and length of the input values are checked. Parameters are also treated as safe text values and non-executable code within the database. If you cannot use a stored procedure, use an SQL statement with parameters. Do not build SQL statements by connecting SQL commands and entering values. Also make sure that the application uses a database login with the least privilege to limit its functionality in the database.

  For more information about SQL injection and further countermeasures, see "SQL injection" of the "Building Secure data Access" unit.

• How to prevent cross-site scripting

  Validates the input type, length, format, and range, and encodes the output. If the output includes input (including Web input), the output is encoded. For example, encode form fields, query string parameters, cookies, and so on, and encode the input that is read from a database (especially a shared database) that cannot assume its data is secure. Encodes the output in a free-form input field that needs to be returned to the client in HTML, and optionally clears the encoding on the licensed element, such as the <b> or tag used for formatting.

  For more information, see Cross-site Scripting for the build ASP. NET page and controls unit.

• How to Manage Secrets

  It is a good idea to look for alternatives to storing secrets. If you must store them, do not store them in clear text in the source code or in the configuration file. Use the Data Protection application Programming Interface (DPAPI) to encrypt secrets to avoid critical management issues.

  For more information, see "Aspnet_setreg.exe and processes, sessions, and identities" of the "Building Secure ASP. NET pages and controls" cell, "encryption" for the "Building Secure Assemblies" unit, and "Securing the ASP. NET Application Security" unit.

• How to safely invoke unmanaged code

  Pay special attention to the arguments passed to the unmanaged API and unmanaged APIs to prevent potential buffer overflows. Verify the length of the input and output string parameters, check the array bounds, and be particularly careful about the length of the file path. Use a custom permission declaration to protect access to unmanaged resources before asserting unmanaged code permissions. If you use SuppressUnmanagedCodeSecurityAttribute to improve performance, be careful.

  For more information, see the "Unmanaged Code" section in "Building Secure Assemblies" and "Code access security Practices" in unit two.

• How to perform secure input validation

  Restrict, reject, and clean up input because validating data of known valid types, patterns, and ranges is much easier than validating data by finding known error characters. Verify the type, length, format, and range of the data. For string input, use regular expressions. To use the Perform type check, use the. NET Framework type System. Sometimes, you might need to clean up your input. An example is to encode the data to ensure its security.

  For input validation design policies, see "Input Validation" in the "Designing guidelines for Secure WEB application" unit. For implementation details, see "Building Secure ASP. NET pages and controls," "Building Secure Web Services," "Building Secure Remote Components," and "Building Secure data Access" in the "Input Validation" section.

• How to guarantee the security of form authentication

  Divide Web sites to isolate publicly accessible pages that anonymous users can access and restricted pages that require authenticated access. Use Secure Sockets Layer (SSL) to protect forms authentication credentials and forms authentication cookies. Limit the session lifetime and ensure that the authentication cookie is transmitted only on HTTPS. Encrypt the authentication cookie, do not keep it on the client computer, and do not use it for personalization purposes, and separate cookies for personalization.

Web Security Solutions