Solutions at a Glance

 

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Improving Web Application Security: Threats and Countermeasures

J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan
Microsoft Corporation

Published: June 2003

Last Revised: January 2006

See the "patterns & practices Security Guidance for Applications Index" for links to additional security resources.

See the Landing Page for the starting point and a complete overview of Improving Web Application Security: Threats and Countermeasures.

Summary: This Chapter provides a road map into the various sections of the guide for you to easily navigate and find solutions to your specific problems.

This document roadmap summarizes the solutions presented in Improving Web Application Security: Threats and Countermeasures. It provides links to the appropriate material in the guide so that you can easily locate the information you need and find solutions to specific problems.

Contents

Architecture and Design Solutions
Development Solutions
Administration Solutions

Architecture and Design Solutions

For architects, the guide provides the following solutions to help you design secure Web applications:

• How to identify and evaluate threats

  Use threat modeling to systematically identify threats rather than applying security in a haphazard manner. Next, rate the threats based on the risk of an attack or occurrence of a security compromise and the potential damage that could result. This allows you to tackle threats in the appropriate order.

  For more information about creating a threat model and evaluating threat risks, see Chapter 3, "Threat Modeling."

• How to create secure designs

  Use tried and tested design principles. Focus on the critical areas where the correct approach is essential and where mistakes are often made. This guide refers to these as application vulnerability categories. They include input validation, authentication, authorization, configuration management, sensitive data protection, session management, cryptography, parameter manipulation, exception management, and auditing and logging considerations. Pay serious attention to deployment issues including topologies, network infrastructure, security policies, and procedures.

  For more information, see Chapter 4, "Design Guidelines for Secure Web Applications."

• How to perform an architecture and design review

  Review your application's design in relation to the target deployment environment and associated security policies. Consider the restrictions imposed by the underlying infrastructure layer security, including perimeter networks, firewalls, remote application servers, and so on. Use application vulnerability categories to help partition your application, and analyze the approach taken for each area.

  For more information, see Chapter 5, "Architecture and Design Review."

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) 5.0 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.

Note   By default, IIS 6.0 has security-related configuration settings similar to those made by the IIS Lockdown Tool. Therefore, you do not need to run the IIS Lockdown Tool on Web servers running IIS 6.0. If you are upgrading from a previous version of IIS (5.0 or lower) to IIS 6.0, it is recommended that you run the IIS Lockdown Tool to enhance the security of your Web server.

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," Chapter 13, "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 Secure 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."

Administration Solutions

For administrators, this guide provides the following solutions:

• How to implement patch management

  Use the Microsoft Baseline Security Analyzer (MBSA) to detect the patches and updates that may be missing from your current installation. Run this on a regular basis, and keep your servers current with the latest patches and updates. Back up servers prior to applying patches, and test patches on test servers prior to installing them on a production server. Also, use the security notification services provided by Microsoft, and subscribe to receive security bulletins via e-mail.

  For more information, see "How To: Implement Patch Management" in the "How To" section of this guide.

• How to make the settings in Machine.config and Web.config more secure

Do not store passwords or sensitive data in plaintext. For example, use the Aspnet_setreg.exe utility to encrypt the values for <processModel>, <identity>, and <sessionState>. Do not reveal exception details to the client. For example do not use mode="Off" for <customErrors> in ASP.NET because it causes detailed error pages that contain system-level information to be returned to the client. Restrict who has access to configuration files and settings. Lock configuration settings if necessary, using the <location> tag and the allowOverride element.

For more information on improving the security of Machine.config and Web.config for your scenario, see Chapter 19, "Securing Your ASP.NET Application and Web Services." For more information on the <location> tag, see "Machine.Config and Web.Config" explained in Chapter 19, "Securing Your ASP.NET Application and Web Services." For more information on Aspnet_setreg.exe, see "Aspnet_setreg.exe and Process, Session, and Identity" in Chapter 19, "Securing Your ASP.NET Application and Web Services."

• How to secure a Web server running the .NET Framework

Apply a methodology to systematically configure the security of your Web server. Secure your accounts, protocols, ports, services, shares, files and directories, and registry. You can use IISLockdown to help automate some of the security configuration. Use a hardened Machine.config to apply stringent security to all .NET Framework applications installed on the server. Most importantly, keep your server current with the latest patches and updates.

For more information, see Chapter 16, "Securing Your Web Server."

• How to secure a database server

  Apply a common methodology to evaluate accounts, protocols, ports, services, shares, files and directories, and the registry. Also evaluate SQL Server® security settings such as the authentication mode and auditing configuration. Evaluate your authorization approach and use of SQL Server logins, users, and roles. Make sure you have the latest service pack and regular monitor for operating system and SQL Server patches and updates.

  For more information, see Chapter 18, "Securing Your Database Server."

• How to secure an application server

  Evaluate accounts, protocols, ports, services, shares, files and directories, and the registry. Use Internet Protocol Security (IPSec) or SSL to secure the communication channel between the Web server and the application server, and between the application server and the database server. Review the security of your Enterprise Services applications, Web services, and remoting applications. Restrict the range of ports with which clients can connect to the application server, and consider using IPSec restrictions to limit the range of clients.

  For more information, see Chapter 17, "Securing Your Application Server."

• How to host multiple ASP.NET applications securely

  Use separate identities to allow you to configure access control lists (ACLs) on secure resources to control which applications have access to them. On the Microsoft Windows Server 2003 operating system, use separate process identities with IIS 6 application pools. On Windows 2000 Server, use multiple anonymous Internet user accounts and enable impersonation. With the .NET Framework version 1.1 on both platforms, you can use partial trust levels and use code access security to provide further application isolation. For example, you can use these methods to prevent applications from accessing each other's virtual directories and critical system resources.

  For more information, see Chapter 20, "Hosting Multiple ASP.NET Applications."

• How to secure Web services

  In cross-platform scenarios and where you do not control both endpoints, use the Web Services Enhancements for Microsoft .NET (WSE) to implement message level security solutions that conform to the emerging WS-Security standard. Pass authentication tokens in Simple Object Access Protocol (SOAP) headers. Use XML encryption to ensure that sensitive data remains private. Use digital signatures for message integrity. Within the enterprise where you control both endpoints, you can use the authentication, authorization, and secure communication features provided by the operating system and IIS.

  For more information, see Chapter 17, "Securing Your Application Server," Chapter 19, "Securing Your ASP.NET Application and Web Services." For information about developing secure Web services, see Chapter 12, "Building Secure Web Services."

• How to secure Enterprise Services

  Configure server applications to run using least privileged accounts. Enable COM+ role-based security, and enforce component-level access checks. At the minimum, use call-level authentication to prevent anonymous access. To secure the traffic passed to remote serviced components, use IPSec encrypted channels or use remote procedure call (RPC) encryption. Restrict the range of ports that Distributed COM (DCOM) dynamically allocates or use static endpoint mapping to limit the port range to specific ports. Regularly monitor for Quick Fix Engineer (QFE) updates to the COM+ runtime.

  For more information, see Chapter 17, "Securing Your Application Server."

• How to secure Microsoft .NET Remoting

  Disable remoting on Internet-facing Web servers by mapping .rem and .soap extensions to the ASP.NET HttpForbiddenHandler HTTP module in Machine.config. Host in ASP.NET and use the HttpChannel type name to benefit from ASP.NET and IIS authentication and authorization services. If you need to use the TcpChannel type name, host your remote components in a Windows service and use IPSec to restrict which clients can connect to your server. Use this approach only in a trusted server situation, where the remoting client (for example a Web application) authenticates and authorizes the original callers.

  For more information, see Chapter 17, "Securing Your Application Server."

• How to secure session state

  You need to protect session state while in transit across the network and while in the state store. If you use a remote state store, secure the communication channel to the state store using SSL or IPSec. Also encrypt the connection string in Machine.config. If you use a SQL Server state store, use Windows authentication when you connect to the state store, and limit the application login in the database. If you use the ASP.NET state service, use a least privileged account to run the service, and consider changing the default port that the service listens to. If you do not need the state service, disable it.

  For more information, see "Session State" in Chapter 19, "Securing Your ASP.NET Application and Web Services."

• How to manage application configuration securely

  Remote administration should be limited or avoided. Strong authentication should be required for administrative interfaces. Restrict access to configuration stores through ACLs and permissions. Make sure you have the granularity of authorization required to support separation of duties.

  For general considerations for secure configuration management, see Chapter 4, "Design Guidelines for Secure Web Applications." To verify the secure defaults and ensure that you apply secure machine-wide settings and secure application specific settings, see Chapter 19, "Securing Your ASP.NET Application and Web Services."

• How to secure against denial of service attacks

  Make sure the TCP/IP stack configuration on your server is hardened to protect against attacks such as SYN floods. Configure ASP.NET to limit the size of accepted POST requests and to place limits on request execution times.

  For more information about hardening TCP/IP, see "How To: Harden the TCP/IP Stack" in the "How To" section of this guide. For more information about ASP.NET settings used to help prevent denial of service, see Chapter 19, "Securing Your ASP.NET Application and Web Services."

• How to constrain file I/O

  You can configure code access security policy to ensure that individual assemblies or entire Web applications are limited in their ability to access the file system. For example, by configuring a Web application to run at the Medium trust level, you prevent the application from being able to access files outside of its virtual directory hierarchy.

  Also, by granting a restricted file I/O permission to a particular assembly you can control precisely which files it is able to access and how it should be able to access them.

  For more information, see Chapter 9, "Using Code Access Security with ASP.NET" and "How To: Use Code Access Security Policy to Constrain an Assembly" in the "How To" section of this guide.

• How to perform remote administration

  Terminal Services provides a proprietary protocol (RDP.) This supports authentication and can provide encryption. If you need a file transfer facility, you can install the File Copy utility from the Windows 2000 Server resource kit. The use of IIS Web administration is not recommended and this option is removed if you run IISLockdown. You should consider providing an encrypted channel of communication and using IPSec to limit the computers that can be used to remotely administer your server. You should also limit the number of administration accounts.

  For more information, see the "Remote Administration" sections in Chapter 16, "Securing Your Web Server" and Chapter 18, "Securing Your Database Server."

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

© Microsoft Corporation. All rights reserved.