ASP.NET 1.1 Security Checklist

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

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.

Application Categories Considerations

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

Resources

• See online on MSDN: http://msdn.microsoft.com/library/en-us/dnnetsec/html/CL_SecuAsp.asp