Checklist: Securing ASP.NET

Article
07/14/2010

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

Applies to:

ASP.NET version 1.1

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.

How to Use This Checklist Design Considerations Application Categories Considerations Configuration File Settings

How to Use This Checklist

This checklist is a companion to Chapter 10, "Building Secure ASP.NET Pages and Controls," Chapter 19, "Securing Your ASP.NET Application and Web Services," and Chapter 20, "Hosting Multiple Web Applications." Use it to help you secure an ASP.NET application and also as a snapshot of the corresponding chapters.

Design Considerations

Check	Description
	Security decisions should not rely on client-side validations; they are made on the server side.
	The Web site is partitioned into public access areas and restricted areas that require authentication access. Navigation between these areas should not flow sensitive credentials information.
	The identities used to access remote resources from ASP.NET Web applications are clearly identified.
	Mechanisms have been identified to secure credentials, authentication tickets, and other sensitive information over network and in persistent stores.
	A secure approach to exception management is identified. The application fails securely in the event of exceptions.
	The site has granular authorization checks for pages and directories.
	Web controls, user controls, and resource access code are all partitioned in their own assemblies for granular security.

Application Categories Considerations

Input Validation

Check	Description
	User input is validated for type, length, format, and range. Input is checked for known valid and safe data and then for malicious, dangerous data.
	String form field input is validated using regular expressions (for example, by the RegularExpressionValidator control.)
	Regular HTML controls, query strings, cookies, and other forms of input are validated using the Regex class and/or your custom validation code.
	The RequiredFieldValidator control is used where data must be entered.
	Range checks in server controls are checked by RangeValidator controls.
	Free form input is sanitized to clean malicious data.
	Input file names are well formed and are verifiably valid within the application context.
	Output that includes input is encoded with HtmlEncode and UrlEncode.
	MapPath restricts cross-application mapping where appropriate.
	Character encoding is set by the server (ISO-8859-1 is recommended).
	The ASP.NET version 1.1 validateRequest option is enabled.
	URLScan is installed on the Web server.
	The HttpOnly cookie option is used for defense in depth to help prevent cross-site scripting. (This applies to Internet Explorer 6.1 or later.)
	SQL parameters are used in data access code to validate length and type of data and to help prevent SQL injection.

Authentication

Check	Description
	Site is partitioned to restricted areas and public areas.
	Absolute URLs are used for navigation where the site is partitioned with secure and non-secure folders.
	Secure Sockets Layer (SSL) is used to protect credentials and authentication cookies.
	The slidingExpiration attribute is set to "false" and limited authentication cookie time-outs are used where the cookie is not protected by using SSL.
	The forms authentication cookie is restricted to HTTPS connections by using the requireSSL attribute or the Secure cookie property.
	The authentication cookie is encrypted and integrity checked (protection="All").
	Authentication cookies are not persisted.
	Application cookies have unique path/name combinations.
	Personalization cookies are separate from authentication cookies.
	Passwords are not stored directly in the user store; password digests with salt are stored instead.
	The impersonation credentials (if using a fixed identity) are encrypted in the configuration file by using Aspnet_setreg.exe.
	Strong password policies are implemented for authentication.
	The <credentials> element is not used inside <forms> element for Forms authentication (use it for testing only).

Authorization

Check	Description
	URL authorization is used for page and directory access control.
	File authorization is used with Windows authentication.
	Principal permission demands are used to secure access to classes and members.
	Explicit role checks are used if fine-grained authorization is required.

Configuration Management

Check	Description
	Configuration file retrieval is blocked by using HttpForbiddenHandler.
	A least-privileged account is used to run ASP.NET.
	Custom account credentials (if used) are encrypted on the <processModel> element by using Aspnet_setreg.exe.
	To enforce machine-wide policy, Web.config settings are locked by using allowOveride="false" in Machine.config.

Sensitive Data

Check	Description
	SSL is used to protect sensitive data on the wire.
	Sensitive data is not passed across pages; it is maintained using server-side state management.
	Sensitive data is not stored in cookies, hidden form fields, or query strings.
	Do not cache sensitive data. Output caching is off by default.
	Plain text passwords are avoided in Web.config and Machine.config files. (Aspnet_setreg.exe is used to encrypt credentials.)

Session Management

Check	Description
	The session cookie is protected using SSL on all pages that require authenticated access.
	The session state service is disabled if not used.
	The session state service (if used) runs using a least-privileged account.
	Windows authentication is used to connect to Microsoft® SQL Server® state database.
	Access to state data in the SQL Server is restricted.
	Connection strings are encrypted by using Aspnet_setreg.exe.
	The communication channel to state store is encrypted (IPSec or SSL).

Parameter Manipulation

Check	Description
	View state is protected using message authentication codes (MACs).
	Query strings with server secrets are hashed.
	All input parameters are validated.
	Page.ViewStateUserKey is used to counter one-click attacks.

Exception Management

Check	Description
	Structured exception handling is used.
	Exception details are logged on the server.
	Generic error pages with harmless messages are returned to the client.
	Page-level or application-level error handlers are implemented.
	The application distinguishes between errors and exception conditions.

Auditing and Logging

Check	Description
	Application event sources are created at installation time. If unable to create event sources at installation time, the administrator manually creates new event sources entry in the registry. The ASP.NET process is not allowed to create new event sources by configuring ACL in the registry.

Configuration File Settings

Check	Description
	<trace/> Tracing is not enabled on the production servers. `<trace enabled="false">`
	<globalization> Request and response encoding is appropriately configured.
	<httpRuntime> maxRequestLength is configured to prevent users from uploading very large files (optional).
	<compilation> Debug compiles are not enabled on the production servers by setting debug="false" `<compilation debug="false" . . ./>`
	<pages> If the application does not use view state, enableViewState is set to "false". `<pages enableViewState="false" . . ./>` If the application uses view state, enableViewState is set to "true" and enableViewStateMac is set to "true" to detect view state tampering. `<pages enableViewState="true" enableViewStateMac="true" />`
	<customErrors> Custom error pages are returned to the client and detailed exception details are prevented from being returned by setting mode="On". `<customErrors mode="On" />` A generic error page is specified by the defaultRedirect attribute. `<customErrors mode="On" defaultRedirect="/apperrorpage.htm" />`
	<authentication> The authentication mode is appropriately configured to support application requirements. To enforce the use of a specific authentication type, a <location> element with allowOverride="false" is used. `<location path="" allowOverride="false"> <system.web> <authentication mode="Windows" /> </system.web> </location>`
	<forms> The Web site is partitioned for public and restricted access. The Forms authentication configuration is secure: `<forms loginUrl="Restricted\login.aspx" protection="All" requireSSL="true" timeout="10" name="AppNameCookie" path="/FormsAuth" slidingExpiration="true" />` The authentication cookie is encrypted and integrity checked (protection). SSL is required for authentication cookie (requireSSL). Sliding expiration is set to false if SSL is not used (slidingExpiration). The session lifetime is restricted (timeout). Cookie names and paths are unique (name and path). The <credentials> element is not used.
	<identity> Impersonation identities (if used) are encrypted in the registry by using Aspnet_setreg.exe: `<identity impersonate="true" userName="registry:HKLM\SOFTWARE\YourApp\ identity\ASPNET_SETREG,userName" password="registry:HKLM\SOFTWARE\YourApp\ identity\ASPNET_SETREG,password"/>`
	<authorization> Correct format of role names is verified.
	<machineKey> If multiple ASP.NET Web applications are deployed on the same Web server, the "IsolateApps" setting is used to ensure that a separate key is generated for each Web application. `<machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" validation="SHA1" />` If the ASP. NET Web application is running in a Web farm, specific machine keys are used, and these keys are copied across all servers in the farm. If the view state is enabled, the validation attribute is set to "SHA1". The validation attribute is set to "3DES" if the Forms authentication cookie is to be encrypted for the application.
	<sessionState> If mode="StateServer", then credentials are stored in an encrypted form in the registry by using Aspnet_setreg.exe. If mode="SQLServer", then Windows authentication is used to connect to the state store database and credentials are stored in an encrypted form in the registry by using Aspnet_setreg.exe.
	<httpHandlers> Unused file types are mapped to HttpForbiddenHandler to prevent files from being retrieved over HTTP. For example: `<add verb="" path=".rem" type="System.Web.HttpForbiddenHandler"/>`
	<processModel> A least-privileged account like ASPNET is used to run the ASP.NET process. `<processModel userName="Machine" password="AutoGenerate"` The system account is not used to run the ASP.NET process. The Act as part of the operating system privilege is not granted to the process account. Credentials for custom accounts are encrypted by using Aspnet_setreg.exe. `<processModel userName="registry:HKLM\SOFTWARE\MY_SECURE_APP\ processmodel\ASPNET_SETREG,userName" password="registry:HKLM\SOFTWARE\MY_SECURE_APP\ processmodel\ASPNET_SETREG,password" . . ./>` If the application uses Enterprise Services, comAuthenticationLevel and comImpersonationLevel are configured appropriately. Call level authentication is set at minimum to ensure that all method calls can be authenticated by the remote application. PktPrivacy is used to encrypt and tamper proof the data across the wire in the absence of infrastructure channel security (IPSec). PktIntegrity is used for tamper proofing with no encryption (Eavesdroppers with network monitors can see your data.)
	<webServices> Unused protocols are disabled. Automatic generation of Web Services Description Language (WSDL) is disabled (optional).

Web Farm Considerations

Check	Description
	Session state. To avoid server affinity, the ASP.NET session state is maintained out of process in the ASP.NET SQL Server state database or in the out-of-process state service that runs on a remote machine.
	Encryption and verification. The keys used to encrypt and verify Forms authentication cookies and view state are the same across all servers in a Web farm.
	DPAPI. DPAPI cannot be used with the machine key to encrypt common data that needs to be accessed by all servers in the farm. To encrypt shared data on a remote server, use an alternate implementation, such as 3DES.

Hosting Multiple Applications

Check	Description
	Applications have distinct machine keys. Use IsolateApps on <machineKey> or use per application <machineKey> elements. `<machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" . . . />`
	Unique path/name combinations for Forms authentication cookies are enabled for each application.
	Multiple processes (IIS 6.0 application pools) are used for application isolation on Microsoft Windows® Server 2003.
	Multiple anonymous user accounts (and impersonation) are used for application isolation on Windows 2000.
	Common machine keys are enabled on all servers in a Web farm.
	Separate machine keys for each application are used when hosting multiple applications on a single server.
	Code access security trust levels are used for process isolation and to restrict access to system resources (requires .NET Framework version 1.1).

ACLs and Permissions

Check	Description
	Temporary ASP.NET files `%windir%\Microsoft.NET\Framework\{version}Temporary ASP.NET Files` ASP.NET process account and impersonated identities: Full Control
	Temporary directory `(%temp%)` ASP.NET process account: Full Control
	.NET Framework directory `%windir%\Microsoft.NET\Framework\{version}` ASP.NET process account and impersonated identities: Read and Execute List Folder Contents
	.NET Framework configuration directory `%windir%\Microsoft.NET\Framework\{version}\CONFIG` ASP.NET process account and impersonated Identities: Read and Execute List Folder Contents Read
	Web site root `C:\inetpub\wwwroot` or the path that the default Web site points to ASP.NET process account: Full Control
	System root directory `%windir%\system32` ASP.NET process account: Read
	Global assembly cache `%windir%\assembly` Process account and impersonated identities: Read
	Content directory `C:\inetpub\wwwroot\YourWebApp` Process account: Read and Execute List Folder Contents Read Note With .NET Framework version 1.0, all parent directories from the content directory to the file system root directory also require the above permissions. Parent directories include: `C:\ C:\inetpub\ C:\inetpub\wwwroot\`

Application Bin Directory

Check	Description
	IIS Web permissions are configured. Bin directory does not have Read, Write, or Directory browsing permissions. Execute permissions are set to None.
	Authentication settings are removed (so that all access is denied).

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.