ASP.NET 1.1 Security Checklist: Difference between revisions

From Guidance Share
Jump to navigationJump to search
No edit summary
No edit summary
Line 242: Line 242:

== Resources ==
* See online on MSDN:

[[Category: ASP.NET 1.1]]
[[Category: ASP.NET 1.1]]
[[Category: Checklist]]
[[Category: Checklist]]

Latest revision as of 03:56, 13 December 2007

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


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


  • 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


  • Tracing is not enabled on the production servers.

<trace enabled="false"> <globalization>

  • Request and response encoding is appropriately configured.


  • maxRequestLength is configured to prevent users from uploading very large files (optional).


  • 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">

   			<authentication mode="Windows" />

</location> <forms>

  • The Web site is partitioned for public and restricted access.
  • The Forms authentication configuration is secure:

<forms loginUrl="Restricted\login.aspx"

      	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.


  • Impersonation identities (if used) are encrypted in the registry by using Aspnet_setreg.exe:

<identity impersonate="true"




identity\ASPNET_SETREG,password"/> <authorization>

  • Correct format of role names is verified.


  • 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"

    		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.


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


  • Unused file types are mapped to HttpForbiddenHandler to prevent files from being retrieved over HTTP. For example:

<add verb="*" path="*.rem"



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


  • 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:

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