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

Content directory

 C:\inetpub\wwwroot\YourWebApp 

Process account:

Read and Execute

List Folder Contents

Read

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

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