aspnetsecuritychecklist

Return to HomePage

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

ASP.NET 1.1 Security Checklist

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.

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

Return to HomePage

Return to %5bHomePage%5d
----
 
Note%3a See online on MSDN%3a http%3a//msdn.microsoft.com/library/en-us/dnnetsec/html/CL_SecuAsp.asp
 
%21%21%21 ASP.NET 1.1 Security Checklist
J.D. Meier%2c Alex Mackman%2c Michael Dunner%2c Srinath Vasireddy%2c Ray Escamilla and Anandha Murukan
 
Microsoft Corporation
 
June 2003
 
 
%21%21 Design Considerations
	* Security decisions should not rely on client-side validations%3b 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%2c authentication tickets%2c 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%2c user controls%2c and resource access code are all partitioned in their own assemblies for granular security. 
 
%21%21 Application Categories Considerations
%21%21%21 Input Validation
	* User input is validated for type%2c length%2c format%2c and range. Input is checked for known valid and safe data and then for malicious%2c dangerous data. 
	* String form field input is validated using regular expressions %28for example%2c by the 	%5bRegularExpressionValidator%5d control.%29 
	* Regular HTML controls%2c query strings%2c cookies%2c and other forms of input are validated using the Regex class and/or your custom validation code. 
	* The %5bRequiredFieldValidator%5d control is used where data must be entered. 
	* Range checks in server controls are checked by %5bRangeValidator%5d 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 %5bHtmlEncode%5d and %5bUrlEncode.%5d 
	* %5bMapPath%5d restricts cross-application mapping where appropriate. 
	* Character encoding is set by the server %28ISO-8859-1 is recommended%29. 
	* The ASP.NET version 1.1 validateRequest option is enabled. 
	* %5bURLScan%5d is installed on the Web server. 
	* The %5bHttpOnly%5d cookie option is used for defense in depth to help prevent cross-site scripting. %28This applies to Internet Explorer 6.1 or later.%29 
	* SQL parameters are used in data access code to validate length and type of data and to help prevent SQL injection. 
 
%21%21%21 Authentication
	* Site is partitioned to restricted areas and public areas. 
	* Absolute %5bURLs%5d are used for navigation where the site is partitioned with secure and non-secure folders. 
	* Secure Sockets Layer %28SSL%29 is used to protect credentials and authentication cookies. 
	* The slidingExpiration attribute is set to %22false%22 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 %28protection%3d%22All%22%29. 
	* 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%3b password digests with salt are stored instead. 
	* The impersonation credentials %28if using a fixed identity%29 are encrypted in the configuration file by using Aspnet_setreg.exe. 
	* Strong password policies are implemented for authentication. 
	* The %3ccredentials%3e element is not used inside %3cforms%3e element for Forms authentication %28use it for testing only%29. 
 
%21%21%21 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. 
 
%21%21%21 Configuration Management
	* Configuration file retrieval is blocked by using %5bHttpForbiddenHandler.%5d 
	* A least-privileged account is used to run ASP.NET. 
	* Custom account credentials %28if used%29 are encrypted on the %3cprocessModel%3e element by using Aspnet_setreg.exe. 
	* To enforce machine-wide policy%2c Web.config settings are locked by using allowOveride%3d%22false%22 in Machine.config. 
 
%21%21%21 Sensitive Data
	* SSL is used to protect sensitive data on the wire. 
	* Sensitive data is not passed across pages%3b it is maintained using server-side state management. 
	* Sensitive data is not stored in cookies%2c hidden form fields%2c 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. %28Aspnet_setreg.exe is used to encrypt credentials.%29 
 
%21%21%21 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 %28if used%29 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 %5b%28IPSec%5d or SSL%29. 
 
%21%21%21 Parameter Manipulation
	* View state is protected using message authentication codes %5b%28MACs%29.%5d 
	* Query strings with server secrets are hashed. 
	* All input parameters are validated. 
	* %5bPage.ViewStateUserKey%5d is used to counter one-click attacks. 
 
%21%21%21 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. 
 
%21%21%21 Auditing and Logging
	* The ASP.NET process is configured to allow new event sources to be created at runtime%2c or application event sources to be created at installation time. 
 
%21%21%21 Configuration File Settings
%3ctrace/%3e 
	* Tracing is not enabled on the production servers.
	%3ctrace enabled%3d%22false%22%3e
%3cglobalization%3e 
	* Request and response encoding is appropriately configured.
%3chttpRuntime%3e 
	* %5bmaxRequestLength%5d is configured to prevent users from uploading very large files %28optional%29.
%3ccompilation%3e 
	* Debug compiles are not enabled on the production servers by setting debug%3d%22false%22
	%3ccompilation debug%3d%22false%22 . . ./%3e
%3cpages%3e 
	* If the application does not use view state%2c %5benableViewState%5d is set to %22false%22.
	%3cpages enableViewState%3d%22false%22 . . ./%3e
	* If the application uses view state%2c %5benableViewState%5d is set to %22true%22 and %5benableViewStateMac%5d is set to %22true%22 to detect view state tampering.
	%3cpages enableViewState%3d%22true%22 enableViewStateMac%3d%22true%22 /%3e
%3ccustomErrors%3e 
	* Custom error pages are returned to the client and detailed exception details are prevented from being returned by setting mode%3d%22On%22.
	%3ccustomErrors mode%3d%22On%22 /%3e
	* A generic error page is specified by the defaultRedirect attribute.
	%3ccustomErrors mode%3d%22On%22 defaultRedirect%3d%22/apperrorpage.htm%22 /%3e
%3cauthentication%3e 
	* The authentication mode is appropriately configured to support application requirements. To enforce the use of a specific authentication type%2c a %3clocation%3e element with allowOverride%3d%22false%22 is used.
	%3clocation path%3d%22%22 allowOverride%3d%22false%22%3e
%7b%7b
  		%3csystem.web%3e
    			%3cauthentication mode%3d%22Windows%22 /%3e
  		%3c/system.web%3e
%7d%7d
	%3c/location%3e
%3cforms%3e 
	* The Web site is partitioned for public and restricted access.
	* The Forms authentication configuration is secure%3a
	%3cforms loginUrl%3d%22Restricted%5clogin.aspx%22
%7b%7b
       	protection%3d%22All%22
       	requireSSL%3d%22true%22
       	timeout%3d%2210%22
       	name%3d%22AppNameCookie%22
       	path%3d%22/FormsAuth%22
       	slidingExpiration%3d%22true%22 /%3e
%7d%7d
	* The authentication cookie is encrypted and integrity checked %28protection%29.
 
	* SSL is required for authentication cookie %28requireSSL%29.
	* Sliding expiration is set to false if SSL is not used %28slidingExpiration%29.
	* The session lifetime is restricted %28timeout%29.
	* Cookie names and paths are unique %28name and path%29.
	* The %3ccredentials%3e element is not used.
%3cidentity%3e 
	* Impersonation identities %28if used%29 are encrypted in the registry by using Aspnet_setreg.exe%3a
	%3cidentity impersonate%3d%22true%22
%7b%7b
          	userName%3d%22registry%3aHKLM%5cSOFTWARE%5cYourApp%5c
%7d%7d
	identity%5cASPNET_SETREG%2cuserName%22
%7b%7b
          	password%3d%22registry%3aHKLM%5cSOFTWARE%5cYourApp%5c
%7d%7d
	identity%5cASPNET_SETREG%2cpassword%22/%3e
%3cauthorization%3e 
	* Correct format of role names is verified.
%3cmachineKey%3e 
	* If multiple ASP.NET Web applications are deployed on the same Web server%2c the %22IsolateApps%22 setting is used to ensure that a separate key is generated for each Web application.
	%3cmachineKey validationKey%3d%22AutoGenerate%2cIsolateApps%22
%7b%7b
     		decryptionKey%3d%22AutoGenerate%2cIsolateApps%22
     		validation%3d%22SHA1%22 /%3e
%7d%7d
	* If the ASP. NET Web application is running in a Web farm%2c specific machine keys are used%2c and these keys are copied across all servers in the farm.
	* If the view state is enabled%2c the validation attribute is set to %22SHA1%22.
	* The validation attribute is set to %223DES%22 if the Forms authentication cookie is to be encrypted for the application.
%3csessionState%3e 
	* If mode%3d%22StateServer%22%2c then credentials are stored in an encrypted form in the registry by using Aspnet_setreg.exe.
	* If mode%3d%22SQLServer%22%2c 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.
%3chttpHandlers%3e 
	* Unused file types are mapped to %5bHttpForbiddenHandler%5d to prevent files from being retrieved over HTTP. For example%3a
	%3cadd verb%3d%22*%22 path%3d%22*.rem%22
%7b%7b
     		type%3d%22System.Web.HttpForbiddenHandler%22/%3e
%7d%7d
%3cprocessModel%3e 
	* A least-privileged account like ASPNET is used to run the ASP.NET process.
	%3cprocessModel userName%3d%22Machine%22 password%3d%22AutoGenerate%22
	* 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.
	%3cprocessModel
%7b%7b
  		userName%3d%22registry%3aHKLM%5cSOFTWARE%5cMY_SECURE_APP%5c
  		processmodel%5cASPNET_SETREG%2cuserName%22
  		password%3d%22registry%3aHKLM%5cSOFTWARE%5cMY_SECURE_APP%5c
  		processmodel%5cASPNET_SETREG%2cpassword%22 . . ./%3e
%7d%7d
	* If the application uses Enterprise Services%2c %5bcomAuthenticationLevel%5d and %5bcomImpersonationLevel%5d are configured appropriately.
	* Call level authentication is set at minimum to ensure that all method calls can be authenticated by the remote application.
	* %5bPktPrivacy%5d is used to encrypt and tamper proof the data across the wire in the absence of infrastructure channel security %5b%28IPSec%29.%5d
	* %5bPktIntegrity%5d is used for tamper proofing with no encryption %28Eavesdroppers with network monitors can see your data.%29
%3cwebServices%3e 
	* Unused protocols are disabled.
	* Automatic generation of Web Services Description Language %28WSDL%29 is disabled %28optional%29.
 
%21%21%21 Web Farm Considerations
	* Session state. To avoid server affinity%2c 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%2c use an alternate implementation%2c such as 3DES. 
 
%21%21%21 Hosting Multiple Applications
	* Applications have distinct machine keys. 
	* Use %5bIsolateApps%5d on %3cmachineKey%3e or use per application %3cmachineKey%3e elements.
	%3cmachineKey validationKey%3d%22AutoGenerate%2cIsolateApps%22
		decryptionKey%3d%22AutoGenerate%2cIsolateApps%22 . . . /%3e
	* Unique path/name combinations for Forms authentication cookies are enabled for each application. 
	* Multiple processes %28IIS 6.0 application pools%29 are used for application isolation on Microsoft Windows® Server 2003. 
	* Multiple anonymous user accounts %28and impersonation%29 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 %28requires .NET Framework version 1.1%29. 
 
%21%21%21 %5bACLs%5d and Permissions
	* Temporary ASP.NET files 
		%25windir%25%5cMicrosoft.NET%5cFramework%5c%7bversion%7dTemporary ASP.NET Files
		* ASP.NET process account and impersonated identities%3a Full Control
%7b%7b
 	* Temporary directory 
%7d%7d
		%28%25temp%25%29
		* ASP.NET process account%3a Full Control
	* .NET Framework directory 
		%25windir%25%5cMicrosoft.NET%5cFramework%5c%7bversion%7d
		* ASP.NET process account and impersonated identities%3a
			* Read and Execute
			* List Folder Contents
%7b%7b
 	* .NET Framework configuration directory 
%7d%7d
		%25windir%25%5cMicrosoft.NET%5cFramework%5c%7bversion%7d%5cCONFIG
		* ASP.NET process account and impersonated Identities%3a
			* Read and Execute
			* List Folder Contents
			* Read
	* Web site root 
		C%3a%5cinetpub%5cwwwroot ... or the path that the default Web site points to
		* ASP.NET process account%3a Full Control
%7b%7b
 	* System root directory 
%7d%7d
		%25windir%25%5csystem32
		* ASP.NET process account%3a Read
	* Global assembly cache 
		%25windir%25%5cassembly
		* Process account and impersonated identities%3a Read
%7b%7b
 	* Content directory 
%7d%7d
		%5bC%3a%5cinetpub%5cwwwroot%5cYourWebApp%5d
		* Process account%3a
			* Read and Execute
			* List Folder Contents
			* Read
		* Note   With .NET Framework version 1.0%2c all parent directories from the content directory to the file system root directory also require the above permissions. Parent directories include%3a
	C%3a%5c
	C%3a%5cinetpub%5c
	C%3a%5cinetpub%5cwwwroot%5c
 
%21%21%21 Application Bin Directory
	* IIS Web permissions are configured. 
	* Bin directory does not have Read%2c Write%2c or Directory browsing permissions. Execute permissions are set to None.
	* Authentication settings are removed %28so that all access is denied%29.
 
----
Return to %5bHomePage%5d