ASP.NET 2.0 Security Guidelines - Deployment Considerations

From Guidance Share

Jump to: navigation, search

- J.D. Meier, Alex Mackman, Blaine Wastell, Prashant Bansode, Andy Wigley, Kishore Gopalan


Contents

Use a Least-Privileged Account for Running ASP.NET Applications

On IIS 5, ASP.NET Web applications run by default using the least privileged ASPNET account. On IIS 6, they run inside an application pool using the least privileged Network Service account. If you need to use a custom service account to run your ASP.NET Web application, create a least-privileged account. You might need to create a custom service account to isolate your application from other applications on the same server or to be able to audit each application separately.

To create a least privileged account

  1. Create a local or domain Windows account.
  2. Run the following Aspnet_regiis.exe command to assign the relevant ASP.NET permissions to the account: aspnet_regiis.exe -ga machineName\userName On Windows Server 2003, running the Aspnet_regiis.exe -ga command will add the account to the IIS_WPG group. The IIS_WPG group provides the Log on as a batch job user right and ensures that the necessary file system permissions are granted. Note With ASP.NET Beta 2, the Aspnet_regiis.exe–ga command does not add the account to the IIS_WPG group. However, it will do so prior to the final release of ASP.NET 2.0.
  3. Use the Local Security Policy tool to grant the Windows account the Deny logon locally user right. This reduces the privileges of the account and prevents anyone logging onto Windows locally with the account.
  4. Use IIS Manager to create an application pool running under the new account's identity and assign your ASP.NET application to the pool.

For more information, see How To: Create a Service Account for an ASP.NET 2.0 Application.


Encrypt Configuration Sections That Store Sensitive Data

In ASP.NET version 1.1, you could use the Aspnet_setreg.exe tool to encrypt certain elements in the Web.config and Machine.config files that contain credentials. This tool replaces the credentials in the configuration file with a pointer to a registry key that holds the DPAPI encrypted data. In ASP.NET version 2.0, you can use either the DPAPI or RSA protected configuration providers to encrypt specific sections that contain sensitive data. The sections that usually contain sensitive information that you need to encrypt include <appSettings>, <connectionStrings>, <identity>, and <sessionState>.

To encrypt the <connectionStrings> section by using the DPAPI provider with the machine-key store (the default configuration), run the following command from a command window:

aspnet_regiis -pe "connectionStrings" -app "/MachineDPAPI" -prov "DataProtectionConfigurationProvider"

  • -pe: Specifies the configuration section to encrypt.
  • -app: Specifies your Web application's virtual path. If your application is nested, you need to specify the nested path from the root directory; for example, "/test/aspnet/MachineDPAPI".
  • -prov: Specifies the provider name.

If you need to encrypt configuration file data on multiple servers in a Web farm, you should use RSA protected configuration provider because of the ease with which you can export RSA key containers. For more information, see How To: Encrypt Configuration Sections in ASP.NET 2.0 Using DPAPI and How To: Encrypt Configuration Sections in ASP.NET 2.0 Using RSA.


Consider Your Key Storage Location

The DPAPI and RSA protected configuration providers used to encrypt sensitive data in configuration files can use either machine stores or user stores for key storage. You can either store the key in the machine store and create an ACL for your specific application identity or store the key in a user store. In the latter case, you need to load the user account's profile to access the key.

Use machine-level key storage when:

  • Your application runs on its own dedicated server with no other applications.
  • You have multiple applications on the same server that run using the same identity and you want those applications to be able to share sensitive information and the same encryption key.

Use user-level key storage if you run your application in a shared hosting environment and you want to ensure that your application's sensitive data is not accessible to other applications on the server. In this scenario, each application should have a separate identity so they all have their own individual and private key stores.


Block Protected File Retrieval by Using HttpForbiddenHandler

To prevent protected files being downloaded over HTTP, map them to the ASP.NET HttpForbiddenHandler. HTTP handlers are located in the machine-level Web.config file beneath the <httpHandlers> element. HTTP handlers are responsible for processing Web requests for specific file extensions.

Many well-known file extensions are already mapped to System.Web.HttpForbiddenHandler. For .NET Framework resources, if you do not use a particular file extension, map the extension to System.Web.HttpForbiddenHandler in the machine-level Web.config file, as shown here.


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

This example assumes that your Web server does not host Web services, so the .asmx file extension is mapped to System.Web.HttpForbiddenHandler. If a client requests a path that ends with .asmx, ASP.NET returns a message that says, "This type of page is not served." If your application uses other files with extensions not already mapped, also map these to System.Web.HttpForbiddenHandler.


Configure the MachineKey to Use the Same Keys on All Servers in a Web Farm

If you deploy your application in a Web farm, you must ensure that the configuration files on each server share hashing and encryption keys. These are used by ASP.NET to protect ViewState and forms authentication tickets. Manually generated, common keys are required because you cannot guarantee which server will handle successive requests.

With manually generated key values, the <machineKey> settings should be similar to the following example.


<machineKey validationKey="21F090935F6E49C2C797F69BBAAD8402ABD2EE0B667A8B4
            4EA7DD4374267A75D7AD972A119482D15A4127461DB1DC347C1A63AE5F1CCFAACFF1B72A7F0A281B"
            decryptionKey="261F793EB53B761503AC445E0CA28DA44AA9B3CF06263B77"
            decryption="3DES"
            validation="SHA1" />
 

For more information about how to manually generate keys, see How To: Configure MachineKey in ASP.NET 2.0.


Lock Configuration Settings to Enforce Policy Settings

To prevent individual application's from being able to override configuration settings with their own Web.config files, apply configuration settings centrally in the machine-level Web.config file located in the following directory: %Windir%\Microsoft.NET\Framework\{version}\CONFIG.

To lock the configuration settings for all Web applications on a Web server, place the configuration settings inside a <system.web> element nested within a <location> element and set the allowOverride attribute to false.

The following example enforces the use of Windows authentication for all Web applications on the server.


<location allowOverride="false">
<system.web>
  <authentication mode="Windows"/>
</system.web>
</location>
 

If you need to apply and lock settings for a specific Web application, use the path attribute on the <location> element to identify the Web application as shown here.


<location path="Default Web Site/VDirName">
 <system.web>
   <authentication mode="Windows"/>
   <identity impersonate="false"/>
 </system.web>
</location>
 

If you specify the path, it must be fully qualified and include the Web site name and virtual directory name.

Personal tools