Securing ASP.NET Configuration

Article
10/22/2014

ASP.NET configuration provides functionality for configuring an entire server, an ASP.NET application, or individual pages in application subdirectories. You can configure features, such as authentication modes, page caching, compiler options, custom errors, debug and trace options, and much more. This topic describes how to optimize the security of the configuration features through best practices when configuring local or remote ASP.NET applications. For more information about securing other features of ASP.NET, see the information listed in the See Also section.

Whereas following coding and configuration best practices can help improve the security of your application, it is important that you continually keep your application server up to date with the latest security updates for Microsoft Windows and Microsoft Internet Information Services (IIS), as well as any updates for Microsoft SQL Server or other membership data sources.

For detailed information about best practices for writing secure code and securing applications, see the book "Writing Secure Code" by Michael Howard and David LeBlanc, and the guidance provided by Microsoft Patterns and Practices.

Important Note:
The ASP.NET configuration system only configures ASP.NET resources and features. Use the configuration features of IIS to configure non-ASP.NET resources. For more information about configuring IIS, see Working with the Metabase (IIS 6.0) and IIS Metabase Property Reference.

Configuration File Security

The following table lists the access control lists (ACLs) that are set by default on the Machine.config file and the root Web.config file, both of which are located in the %SystemRoot%\Microsoft.NET\Framework\version\CONFIG directory. These ACLs are also set on the directory itself, but they include Modify permissions for the Power Users group. The directory is read-only.

Windows account	Permissions
Administrators	Full control
ASP.NET Machine Account (<server>\ASPNET)	Read and Execute
IIS_WPG (<server>\IIS_WPG)	Read and Execute
LOCAL SERVICE	Read and Execute
NETWORK SERVICE	Read and Execute
Power Users (<server>\Power Users)	Modify
SYSTEM	Full control
Users (<server>\Users)	Read and Execute

The following table lists the ACLs that should be set on Web.config files and on any files listed in configSource attributes.

Windows account	Permissions
Administrators	Full control
IIS_WPG (<server>\IIS_WPG)	Read and Execute
INTERACTIVE	Read
Internet Guest Account (<server>\IUSR_<server>)	Read
NETWORK	Read
NETWORK SERVICE	Read
SYSTEM	Full control
Users (<server>\Users)	Read and Execute
ASP.NET Web Site Administration Tool account	Special

The ASP.NET configuration system honors the ACLs that are set on configuration files, regardless of how the configuration settings are edited. For more information, see Editing ASP.NET Configuration Files.

Securing Configuration Values

When storing sensitive information in a configuration file for an application, you should encrypt the sensitive values using protected configuration. Information that is especially sensitive includes the encryption keys that are stored in the machineKey configuration element and the connection strings to a data source that are stored in the connectionStrings configuration element. For more information, see Encrypting Configuration Information Using Protected Configuration.

Protecting Configuration Encryption Key Containers

A critical aspect of using an encryption key is the protection of the file, also called container, in which the key is stored. One important thing to keep in mind is the level of protection associated with the container. Note that the container is stored in a regular operating system file and access to the encryption key is being regulated by the ACLs on the file. The ACLs can be inherited from the folder where the file is created. Key containers with local machine scope (useMachineContainer"true") are stored in a hidden folder at %ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys.

By default, the user who created the key container will have full access to the key. Other users (including the Administrators group) might or might not have access to the container, depending on the ACLs set on the container. Other users can receive access to the container by using the –pa switch of the ASP.NET IIS Registration Tool (ASP.NET IIS Registration Tool (Aspnet_regiis.exe)). Users trying to encrypt or decrypt with the specified key must have the required permissions to access the key container.

In some cases, a user that does not have administrative privileges can nonetheless create an encryption key. This can happen if an application requests a configuration encryption when a key does not exist. Note that the container will be created if it does not exist, and an encryption operation is executed.

In this case, the .NET Framework creates the needed key and related container with the ACLs of the current user. The potential problem here is that a user with administrative privileges could be denied access to the encryption key container. Administrators can regain access to the key by taking ownership of the physical file on the folder mentioned above. The suggested guidelines call for a user with administrative privileges to create the needed keys before they are used, and thus avoid creating them at the time of encryption.

Securing Configuration in a Shared Hosting Environment

In a shared hosting environment, malicious users can potentially modify configuration settings through direct modification of the configuration files, modification through the configuration APIs, and other administration and configuration tools. You can help prevent modification to your application configuration by locking down configuration sections. You do this by adding location elements to the Machine.config file or to any configuration file that is located higher in the hierarchy than the configuration file that you want to restrict. The location element is used to prevent child configuration files from altering settings. For more information, see How to: Lock ASP.NET Configuration Settings and How to: Configure Specific Directories Using Location Settings.

Remote Configuration

Remote configuration is disabled by default. When enabled, the user is authenticated at the DCOM level and only local administrators are authorized to read or write configuration data. For more information, see Editing ASP.NET Remote Configuration Files.

Custom Configuration Providers

Regardless of the current user's security token, custom section-handler code runs using the credentials of the hosting process account. For Web scenarios, this is the <server>\ASPNET account on Windows 2000 and Windows XP, the NETWORK SERVICE account on Windows Server 2003, or an explicitly configured user account. For client scenarios, this is the identity of the process that is currently running.

The configuration system sets permissions before calling a custom configuration section handler, and the call is not trusted in any way by the .NET Framework. The call runs with the trust permission of the application. The ASP.NET configuration system trusts the %SystemRoot%\Microsoft.NET\Framework\version\CONFIG directory, but it does not trust directories that are located lower in the hierarchy.

A custom configuration section handler should set Code Access Security (CAS) demand attributes to obtain permissions. For more information, see ASP.NET Code Access Security or Code Access Security Basics.

Holding a File-Lock on a Configuration File

Only multiple attempts to save to a configuration file or open a file handle can lock a configuration file. A malicious user might attempt to lock the Machine.config file or the root Web.config file, but Full trust is required to do that, and is disabled in ASP.NET by default.

Using the Configuration API to Read Arbitrary Files

The classes of the configuration API cannot read any directories that are not part of the application domain, or any files that do not have a .config file name extension.

IIS Metabase Settings Apply to ASP.NET Requests

When IIS receives a request for an ASP.NET application, the IIS metabase settings are applied to the ASP.NET application regardless of the ASP.NET configuration settings for that application. This constraint can result in ASP.NET applications that are inaccessible to your users or have less restrictive security settings.

For example, if the security settings in the IIS metabase are set to allow site access only to authenticated users while security settings in the Web.config file are set to allow anonymous access to the site, anonymous users would be denied access to the site. To remedy this, you would configure the Web application in IIS Manager to allow anonymous users.

For more information about securing IIS features, see Security in IIS 6.0.

Error Messages and Events

The following sections discuss how you can mitigate potential security risks that are exposed by unexpected error messages and events.

Exceptions

To help prevent sensitive information from being exposed to unwanted sources, configure your application either to not display detailed error messages or to display detailed error messages only when the client is the Web server itself. For more information, see customErrors Element (ASP.NET Settings Schema).

Event Log

If your server is running Windows Server 2003, you can improve the security of your application by securing the event log, and by setting parameters regarding the size, retention, and other features of the event log to help prevent an indirect denial of service attack. For more information about configuring event logs, search for "Event Viewer" in Windows Help and Support.

Health Monitoring

Successful and failed logon attempts are logged using the ASP.NET health-monitoring feature. In the default configuration, this means that failed login attempts will record the user name and other diagnostic information in the Application event log. Ensure that access to the event log is restricted to help keep this information private.

Partager via