Development Solutions


For developers, this guide provides the following solutions:

  • What is .NET Framework security ?

    The .NET Framework provides user and code security models that allow you to restrict what users can do and what code can do. To program role-based security and code access security, use types from the System.Security namespace. The .NET Framework also provides the System.Security.Cryptography namespace, which exposes symmetric and asymmetric encryption and decryption, hashing, random number generation, support for digital signatures, and more.

    To understand the .NET Framework security landscape, see Chapter 6, ".NET Security Overview."

  • How to write secure managed code

    Use strong names to digitally sign your assemblies and to make them tamperproof. At the same time you need to be aware of strong name issues when you use strong name assemblies with ASP.NET. Reduce your assembly attack profile by adhering to solid object oriented design principles, and then use code access security to further restrict which code can call your code. Use structured exception handling to prevent sensitive information from propagating beyond your current trust boundary and to develop more robust code. Avoid canonicalization issues, particularly with input file names and URLs.

    For information about how to improve the security of your managed code, see Chapter 7, "Building Secure Assemblies." For more information about how to use code access security effectively to further improve security, see Chapter 8, "Code Access Security in Practice." For information about performing managed code reviews, see Chapter 21, "Code Review."

  • How to handle exceptions securely

    Do not reveal internal system or application details, such as stack traces, SQL statement fragments , and so on. Ensure that this type of information is not allowed to propagate to the end user or beyond your current trust boundary.

    Fail securely in the event of an exception, and make sure your application denies access and is not left in an insecure state. Do not log sensitive or private data such as passwords, which could be compromised. When you log or report exceptions, if user input is included in exception messages, validate it or sanitize it. 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" sections in Chapter 7, "Building Secure Assemblies," and in Chapter 10, "Building Secure ASP.NET Pages and Controls."

  • How to perform security reviews of managed code

    Use analysis tools such as FxCop to analyze binary assemblies and to ensure that they conform to the .NET Framework design guidelines. Fix any security vulnerabilities identified by your analysis tools. Use a text search facility to scan your source code base for hard-coded secrets such as passwords. Then, review specific elements of your application including Web pages and controls, data access code, Web services, serviced components , and so on. Pay particular attention to SQL injection and cross-site scripting vulnerabilities.

    Also review the use of sensitive code access security techniques such as link demands and asserts. For more information, see Chapter 21, "Code Review."

  • How to secure a developer workstation

    You can apply a methodology when securing your workstation. Secure your accounts, protocols, ports, services, shares, files and directories, and registry. Most importantly, keep your workstation current with the latest patches and updates. If you run Internet Information Services (IIS) on Microsoft Windows XP or Windows 2000, then run IISLockdown. IISLockdown applies secures IIS configurations and installs the URLScan Internet Security Application Programming Interface (ISAPI) filter, which detects and rejects potentially malicious HTTP requests . You may need to modify the default URLScan configuration, for example, so you can debug Web applications during development and testing.

    For more information, see "How To: Secure Your Developer Workstation," in the "How To" section of this guide.

  • How to use code access security with ASP.NET

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

    For more information about using code access security from ASP.NET, developing partial trust Web applications, and sandboxing privileged code, see Chapter 9, "Using Code Access Security with ASP.NET."

    For more information about code access security fundamentals, see Chapter 8, "Code Access Security in Practice."

    For more information about the code access security issues that you need to consider when developing managed code, see the "Code Access Security Considerations" sections in Chapter 11, "Building Secure Serviced Components," Chapter 12, "Building Secure Web Services," "Building Secure Remoted Components," and Chapter 14, "Building Secure Data Access."

  • How to write least privileged code

    You can restrict what code can do regardless of the account used to run the code. You can use code access security to constrain the resources and operations that your code is allowed to access, either by configuring policy or how you write your code. If your code does not need to access a resource or perform a sensitive operation such as calling unmanaged code, you can use declarative security attributes to ensure that your code cannot be granted this permission by an administrator.

    For more information, see Chapter 8, "Code Access Security in Practice."

  • How to constrain file I/O

    You can use code access security to constrain an assembly's ability to access areas of the file system and perform file I/O. For example, you can constrain a Web application so that it can only perform file I/O beneath its virtual directory hierarchy. You can also constrain file I/O to specific directories. You can do this programmatically or by configuring code access security policy.

    For more information, see "File I/O" in Chapter 8, "Code Access Security in Practice" and "Medium Trust" in Chapter 9, "Using Code Access Security with ASP.NET." For more information about configuring code access security policy, see "How To: Use Code Access Security Policy to Constrain an Assembly" in the "How To" section of this guide.

  • How to prevent SQL injection

    Use parameterized stored procedures for data access. The use of parameters ensures that input values are checked for type and length. Parameters are also treated as safe literal values and not executable code within the database. If you cannot use stored procedures, use SQL statements with parameters. Do not build SQL statements by concatenating input values with SQL commands. Also, ensure that your application uses a least privileged database login to constrain its capabilities in the database.

    For more information about SQL injection and for further countermeasures, see "SQL Injection" in Chapter 14, "Building Secure Data Access."

  • How to prevent cross-site scripting

    Validate input for type, length, format, and range, and encode output. Encode output if it includes input, including Web input. For example, encode form fields, query string parameters, cookies and so on, and encode input read from a database ( especially a shared database) where you cannot assume the data is safe. For free format input fields that you need to return to the client as HTML, encode the output and then selectively remove the encoding on permitted elements such as the <b> or <i> tags for formatting.

    For more information, see "Cross-Site Scripting" in Chapter 10, "Building ASP.NET Pages and Controls."

  • How to manage secrets

    Look for alternate approaches to avoid storing secrets in the first place. If you must store them, do not store them in clear text in source code or in configuration files. Encrypt secrets with the Data Protection Application Programming Interface (DPAPI) to avoid key management issues.

    For more information, see "Sensitive Data" in Chapter 10, "Building Secure ASP.NET Pages and Controls," "Cryptography" in Chapter 7, "Building Secure Assemblies," and "Aspnet_setreg.exe and Process, Session, and Identity" in Chapter 19, " Securing Your ASP.NET Application and Web Services."

  • How to call unmanaged code securely

    Pay particular attention to the parameters passed to and from unmanaged APIs, and guard against potential buffer overflows. Validate the lengths of input and output string parameters, check array bounds, and be particularly careful with file path lengths. Use custom permission demands to protect access to unmanaged resources before asserting the unmanaged code permission. Use caution if you use SuppressUnmanagedCodeSecurityAttribute to improve performance.

    For more information, see the "Unmanaged Code" sections in Chapter 7, "Building Secure Assemblies," and Chapter 8, "Code Access Security in Practice."

  • How to perform secure input validation

    Constrain, reject, and sanitize your input because it is much easier to validate data for known valid types, patterns, and ranges than it is to validate data by looking for known bad characters . Validate data for type, length, format, and range. For string input, use regular expressions. To perform type checks, use the .NET Framework type system. On occasion, you may need to sanitize input. An example is encoding data to make it safe.

    For input validation design strategies, see "Input Validation" in Chapter 4, "Design Guidelines for Secure Web Applications." For implementation details, see the "Input Validation" sections in Chapter 10, "Building Secure ASP.NET Pages and Controls," Chapter 12, "Building Secure Web Services," Chapter 13, "Building Secure Remoted Components," and Chapter 14, "Building Secure Data Access."

  • How to secure Forms authentication

    Partition your Web site to separate publicly accessible pages available to anonymous users and restricted pages which require authenticated access. Use Secure Sockets Layer (SSL) to protect the forms authentication credentials and the forms authentication cookie. Limit session lifetime and ensure that the authentication cookie is passed over HTTPS only. Encrypt the authentication cookie, do not persist it on the client computer, and do not use it for personalization purposes; use a separate cookie for personalization.

    For more information, see the "Authentication" sections in Chapter 19, "Securing Your ASP.NET Application and Web Services," and Chapter 10, "Building Secure ASP.NET Pages and Controls."




Improving Web Application Security. Threats and Countermeasures
Improving Web Application Security: Threats and Countermeasures
ISBN: 0735618429
EAN: 2147483647
Year: 2003
Pages: 613

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net