Machine.Config | Improving Web Application Security: Threats and Countermeasures

The .NET Framework configuration for all applications on your server is maintained in Machine.config. For the purposes of the security review, this section examines the settings in Machine.config from top to bottom and considers only those settings that relate to security.

The majority of security settings are contained beneath the <system.web> element, with the notable exception of Web service configuration and .NET Remoting configuration. The review process for Web services and .NET Remoting configuration is presented later in this chapter.

For more information and background about the issues raised by the following review questions, see Chapter 19, "Securing Your ASP.NET Application and Web Services." The following elements are reviewed in this section:

<trace>	<authentication>	<sessionState>
<httpRunTime>	<identity>	<httpHandlers>
<compilation>	<authorization>	<processModel>
<pages>	<machineKey>
<customErrors>	<trust>

<trace>

Make sure tracing is disabled with the following setting.

 <trace enabled="false" ... />

<httpRunTime>

Verify the value of the maxRequestLength attribute on the <httpRunTime> element. You can use this value to prevent users from uploading very large files. The maximum allowed value is 4 MB.

<compilation>

Check that you do not compile debug binaries. Make sure the debug attribute is set to false .

 <compilation debug="false" ... />

<pages>

The <pages> element controls default page level configuration settings. From a security perspective, review the view state and session state settings.

Do you use view state?

If enableViewState is set to true , make sure that enableViewStateMac is also set to true to protect the view state over the network. Also make sure that you review the <machineKey> configuration because this specifies the encryption and hashing algorithms to use together with the associated keys.
Do you use session state?

If enableSessionState is set to true , make sure you review the <sessionState> element configuration.

<customErrors>

Make sure that the mode attribute is set to On to ensure that detailed exception information is not disclosed to the client. Also check that a default error page is specified via the defaultRedirect attribute.

 <customErrors mode="On" defaultRedirect="/apperrorpage.htm" />

<authentication>

This element governs your application's authentication mechanism. Check the mode attribute to see which authentication mechanism is configured and then use the specific review questions for your configured authentication mode.

 <authentication mode="[WindowsFormsPassportNone"] />

Forms Authentication

Review the following questions to verify your Forms authentication configuration.

Do you encrypt the authentication cookie?

Cookies should be encrypted and checked for integrity to detect tampering even over an SSL channel because cookies can be stolen through cross-site scripting (XSS) attacks. Check that the protection attribute of the <forms> element is set to All .
```
 <forms protection="All" .../>   All indicates encryption and verification 
```
Do you use SSL with Forms authentication?

SSL prevents session hijacking and cookie replay attacks. Check the requireSSL attribute of the <forms> element.
```
 <forms requireSSL="true" ... /> 
```
Do you limit authentication cookie lifetime?

Minimize the cookie timeout to limit the amount of time an attacker can use the cookie to access your application. Check the timeout attribute on the <forms> element.
```
 <forms timeout="10" ... /> 
```
Do you use sliding expiration?

Check the slidingExpiration attribute. slidingExpiration="true" means that the cookie expires at a fixed duration after its initial duration. The timeout clock is not reset after each request. Use of a sliding expiration is particularly recommended for applications that do not use SSL on all pages to protect the cookie.
Do you use unique cookie paths and names ?

Check that you use a separate cookie name and path for each Web application. This ensures that users who are authenticated against one application are not treated as authenticated when using a second application hosted by the same Web server. Check the path and name attributes on the <forms> element.
```
 <forms name=".ASPXAUTH" path="/" ... /> 
```
Do you use the <credentials> element?

You should not use the <credentials> element on production servers. This element is intended for development and testing purposes only. Credentials should instead be stored in Microsoft Active Directory directory service or SQL Server.
How do you store credentials?

If your application uses Windows authentication, credentials are stored in Active Directory, which passes the credential management issue to the operating environment. If your application uses Forms authentication, make sure you use a SQL Server or Active Directory credential store.
Do you store password hashes?

Make sure passwords are not stored in the database. Instead, store password hashes with added salt to foil dictionary attacks.
Do you use strong passwords?

Your application should enforce the use of strong passwords. A good way to do this is to use a regular expression in the Forms logon page.

<identity>

The following questions help verify your impersonation configuration specified on the <identity> element:

Do you impersonate the original caller?

If the impersonate attribute is set to true and you do not specify userName or password attributes, you impersonate the IIS authenticated identity, which may be the anonymous Internet user account.

Make sure that ACLs are configured to allow the impersonated identity access only to those resources that it needs to gain access to.
Do you impersonate a fixed identity?

If you impersonate and set the userName and password attributes, you impersonate a fixed identity and this identity is used for resource access.

Make sure you do not specify plaintext credentials on the <identity> element. Instead, use Aspnet_setreg.exe to store encrypted credentials in the registry.

On Windows 2000 this approach forces you to grant the "Act as part of the operating system" user right to the ASP.NET process account, which is not recommended. For alternative approaches, see Chapter 19, "Securing Your ASP.NET Application and Web Services."

<authorization>

This element controls ASP.NET URL authorization and specifically the ability of Web clients to gain access to specific folders, pages, and resources.

Have you used the correct format for user and role names?

When you have <authentication mode="Windows" /> , you are authorizing access to Windows user and group accounts.

User names take the form "DomainName\WindowsUserName". Role names take the form "DomainName\WindowsGroupName".

Note
The local administrators group is referred to as "BUILTIN\Administrators". The local users group is referred to as "BUILTIN\Users".

When you have <authentication mode="Forms" /> , you are authorizing against the identity that is authenticated by the application. Normally, you authorize against the roles that are retrieved from the database. Role names are application specific.

<machineKey>

This element is used to specify encryption and validation keys, and the algorithms used to protect Forms authentication cookies and page level view state.

Do you run multiple applications on the same server?

If so, use the IsolateApps setting to ensure a separate key is generated for each Web application.
```
 <machineKey validationKey="AutoGenerate,IsolateApps"             decryptionKey="AutoGenerate,IsolateApps" validation="SHA1"/> 
```
Do you run in a Web farm?

If so, make sure that you use specific machine keys and copy them across all servers in the farm.
Do you protect view state?

If you protect view state, for example, by setting enableViewSetMac="true" on the <pages> element, set validation="SHA1" (Secure Hash Algorithm) or "3DES" on the <machineKey> element. The Triple Data Encryption Standard (3DES) setting is required if you also encrypt the Forms authentication cookie by setting protection="All" on the <forms> element.

<trust>

The <trust> element determines the code access security trust level used to run ASP.NET Web applications and Web services.

What version of the .NET Framework do you run?

If you run .NET Framework 1.0 then the trust level must be set to Full . For versions equal to or greater than 1.1, you can change it to one of the following:
```
  <trust level="Full" originUrl=""/> 
```
What trust level do you use?

Based on security policy and the agreement with the development team; set an appropriate trust level for the application either in Web.config or in Machine.config.

<sessionState>

The sessionState element configures user session state management for your application. Review the following questions:

Do you use a remote state store?

Check the state store by examining the mode attribute.
```
 <sessionState mode="OffInprocstateServerSQLServer" ... /> 
```
If you use a remote state store and the mode attribute is set to stateServer or SQLServer , check the stateConnectionString and sqlConnectionString attributes respectively. So that credentials are not included in the database connection string, make sure the connection strings are secured in encrypted format in the registry using the Aspnet_setreg.exe tool, or that Windows authentication is used to connect to the SQL Server state store.

The following configuration shows what the stateConnectionString looks like when Aspnet_setreg.exe has been used to encrypt the string in the registry.
```
   <sessionState mode="StateServer"           stateConnectionString="registry:HKLM\SOFTWARE\YourSecureApp\           identity\ASPNET_SETREG,stateConnectionString" /> 
```
Do you use Windows authentication to the state database?

If you use the SQL Server state store, check to see if you use Windows authentication to connect to the state database. This means that credentials are not stored in the connection string and that credentials are not transmitted over the wire.

If you must use SQL authentication, make sure the connection string is encrypted in the registry and that a server certificate is installed on the database server to ensure that credentials are encrypted over the wire.

<httpHandlers>

This element lists the HTTP handlers that process requests for specific file types. Check to ensure that you have disabled all unused file types.

Map unused file types to System.Web.HttpForbiddenHandler to prevent their HTTP retrieval. For example, if your application does not use Web services, map the .asmx extension as follows :

 <httpHandlers>   <add verb="*" path="*.asmx" type="System.Web.HttpForbiddenHandler"/> </httpHandlers>

<processModel>

The identity under which the ASP.NET worker process runs is controlled by settings on the <processModel> element in Machine.config. The following review questions help verify your process identity settings:

What identity do you use to run ASP.NET?

Check the userName and password attributes. Ideally, you use the following configuration that results in the ASP.NET process running under the least privileged ASPNET account.
```
 <processModel userName="Machine" password="AutoGenerate" . . ./> 
```
Do you encrypt the <processModel> credentials?

If you use a custom account, make sure that the account credentials are not specified in plaintext in Machine.config. Make sure the Aspnet_setreg.exe utility has been used to store encrypted credentials in the registry. If this has been used, the userName and password attributes look similar to the settings shown below:
```
 <processModel         userName="registry:HKLM\SOFTWARE\YourSecureApp\processModel\                   ASPNET_SETREG,userName"         password="registry:HKLM\SOFTWARE\YourSecureApp\processModel\                   ASPNET_SETREG,password" . . ./> 
```
Do you use a least privileged account?

The default ASPNET account is a least privileged local account designed to run ASP.NET. To use it for remote resource access, you need to create a duplicate account on the remote server. Alternatively, you can create a least privileged domain account.

Check that the account is not a member of the Users group, and view the user rights assignment in the Local Security Policy tool to confirm it is not granted any extended or unnecessary user rights. Make sure it is not granted the "Act as part of the operating system" user right.