ASP.NET 2.0 Security Questions and Answers - Configuration

From Guidance Share

Jump to: navigation, search


What does a secure web.config look like?

A secure web.config file should conform to the following guidelines:

  • connectionStrings configuration section is encrypted using aspnet_regiis.exe utility.
  • All the configuration sections which store user credentials or sensitive data are encrypted using aspnet_regiis.exe utility.
  • Trace is disabled for the application and customErrors mode is set to “On”, so that no detailed error message are returned to the user.
  • When using Forms authentication, the authentication ticket is secured via the configuration setting. Correct membership provider is configured and set as defaultProvider.
  • When using role manager’s role caching feature the authorization cookie is secured via configuration settings.
  • Impersonation is turned off if not required.
  • Only authenticated users have access to the secured part of the web site.
  • Session state is turned off if not used.
  • In machineKey element decryptionKey and validationKey are separate for each application where as same keys are used in Web Farm scenario on each machine for the application.
  • Application exception details are not propagated to the client.
  • A trust level that matches your application's requirements precisely is specified and it does not grant more permissions than is required by your application.

More information

For more information on securing your application's web.config, see, “How To: Perform a Security Deployment Review for ASP.NET 2.0” at

How do I encrypt sensitive data in machine.config or web.config file?

In ASP.NET 2.0, use the Aspnet_regiis.exe tool with the -pe (provider encryption) option to encrypt sections of Machine.config and Web.config files.

To encrypt a configuration section for example <connectionStrings> section using the DPAPI provider, storing the encryption key in the machine 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 it’s a nested application, you need to specify the nested path from the root directory, for example “/test/aspnet/MachineDPAPI”
  • prov: specifies the provider name.

The .NET Framework 2.0 SDK provides two different Protected Configuration providers, which you use with the aspnet_regiis.exe tool:

  • RSAProtectedConfigurationProvider. This is the default provider and uses the RSA public key encryption to encrypt and decrypt data. Use this provider to encrypt configuration files for use on multiple Windows Servers in a Web farm.
  • DPAPIProtectedConfigurationProvider. This provider uses the Windows Data Protection API (DPAPI) to encrypt and decrypt data. Use this provider to encrypt configuration files for use on a single Windows Server.

The following sections often contain sensitive information that you need to encrypt:

  • <appSettings>. Custom application settings.
  • <connectionStrings>. Connection strings.
  • <identity>. Web application identity. Can contain impersonation credentials.
  • <sessionState>. Contains connection string for out of process session provider.

You so not need any special steps for decryption, as the ASP.NET runtime takes care of this for you.

You cannot use the Aspnet_regiis.exe tool and protected configuration to encrypt the following sections in Web.config and Machine.config:

 <processModel>, <runtime>, <mscorlib>, <startup>, 
 <system.runtime.remoting>, <protectedData>, <satelliteassemblies>, 
 <cryptographySettings>,<cryptoNameMapping>, and <cryptoClasses>. 

For these sections, use the Aspnet_setreg.exe tool. You can also use this tool with ASP.NET 1.1. For more information on AspNet-setreg.exe, see Microsoft Knowledge Base article 329290, "How to use the ASP.NET utility to encrypt credentials and session state connection strings" at;en-us;329290.

More Information

For more information on encrypting configuration section, see

How do I run an ASP.NET application with a particular identity?

In IIS 6.0, use IIS Manager to create an application pool running as a specific identity. Use IIS Manager to assign your application to that application pool.

Running ASP.NET application with a specific identities helps to isolate your application isolation, allows you to restrict application resources to your application's account, allows you to use Windows auditing to track the activity of the application separately from other applications.

In IIS 5.0, you can configure the ASP.NET process identity by setting the userName and password attributes on the <processModel> element in Machine.config. If you do this, you should encrypt the credentials by using the aspnet_setreg.exe utility.

More Information

For more information on creating secure accounts for your ASP.NET applications, see “How To: Create a service account for an ASP.NET 2.0 application” at

How do I create a service account for running my ASP.NET applications?

  • Create a Windows account
  • 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 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 permission and ensures that the necessary file system permissions are granted.

    Note: At the time of this writing, the aspnet_regiis –ga command on .NET Framework 2.0 beta 2 does not add the account to the IIS_WPG group and this must be done manually. The release version of the .NET Framework 2.0 will fix this issue and the account will be added to the IIS_WPG group.

  • 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 this account.
  • Use IIS Manager to create an application pool running under the new account's identity and assign your ASP.NET application(s) to this pool.

More Information

For more information on creating secure accounts for your ASP.NET applications, see “How To: Create a service account for an ASP.NET 2.0 application” at

Do I need to create a unique user account for each application pool?

No, you don’t need to create a unique user account for each application pool. However, you might want to do so if you want to audit and authorize each application separately. This is especially the case if you're in a hosted environment running multiple web applications on the same server.

Maintaining a separate identity for each application in such scenarios enables process isolation and auditing for each application. You can create ACL's for the various operating system resources (includes file system) on an individual application's identity. You also have the ability to establish granular database permissions, which might vary for each application.

More information For more information on creating user accounts for ASP.NET applications, see “How To: Create a service account for an ASP.NET 2.0 application” at

How do I lock configuration settings?

To lock the configuration settings for all the Web applications on a Web server to prevent an individual application from overriding them, place the configuration settings inside a <system.web> element nested within a <location> element in the machine-level Web.config file, and then 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">
    <authentication mode="Windows"/>

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">
    <authentication mode="Windows"/>
    <identity impersonate="false"/>

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

Important: If it is critical that there are no cross-application breaches, then it better to configure the web.config file in the /VDirName for locking the configuration instead of using path attribute to lock the specific web application.

Personal tools