aspnetsecuritychecklist

Cancel Edit [WikiEntry.PreviewButtonText] Save
Return to PatternsAndPracticesSecurityWiki

ASP.NET 1.1 Security Checklist


Note: See online on MSDN: http://msdn.microsoft.com/library/en-us/dnnetsec/html/CL_SecuAsp.asp
J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan

Microsoft Corporation

June 2003


Design Considerations

* 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.

Input Validation

* 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

* 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

* 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

* 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

* 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

* 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

* 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

* 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

* The ASP.NET process is configured to allow new event sources to be created at runtime, or application event sources to be created at installation time.

Configuration File Settings

<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

* 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

* 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

* 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

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


Return to SecurityChecklists
Cancel Edit [WikiEntry.PreviewButtonText] Save
Microsoft Communities