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

The configuration management provided by the .NET Framework encompasses a broad range of settings that allow an administrator to manage the Web application and its environment. These settings are stored in XML configuration files, some of which control machine-wide settings, while others control application-specific configuration.

XML configuration files can be edited with any text editor, such as Notepad, or with XML editors. XML tags are case sensitive, so ensure that the correct case is used.

Figure 19.1 shows the configuration files used to configure ASP.NET Web applications that are available to administrators.

Figure 19.1: ASP.NET configuration files

The Machine.config and Web.config files share many of the same configuration sections and XML elements. Machine.config is used to apply machine-wide policy to all .NET Framework applications running on the local computer. Developers can also use application-specific Web.config files to customize settings for individual applications.

Note	Windows executables, such as WinForm applications, are configured using configuration files. The names of these files are derived from the application executable name, for example, App.exe.config, where app is the application name .

Changes that you make to configuration files are applied dynamically and do not normally require that you restart the server or any service, except if changes are made to the <processModel> element in Machine.config, which is discussed later in this chapter.

Table 19.1 shows where the configuration files are located.

Table 19.1: Configuration File Locations
Configuration file	Location
Machine.config(one per machine per installed version of the .NET Framework)	%windir%\Microsoft.NET\Framework\{version}\CONFIG
Web.config(zero, one, or many per application)	\inetpub\ wwwroot \web.config \inetpub\wwwroot\YourApplication\web.config \inetpub\wwwroot\YourApplication\SubDir\web.config
Enterprisesec.config( enterprise-level CAS) configuration)	%windir%\Microsoft.NET\Framework\{version}\CONFIG
Security.config(machine-level CAS configuration)	%windir%\Microsoft.NET\Framework\{version}\CONFIG
Security.config( user -level CAS configuration)	\Documents and Settings\{user}\Application Data
\Microsoft\CLR Security Config\{version} Web_hightrust.config Web_mediumtrust.config Web_lowtrust.config Web_minimaltrust.config(ASP.NET Web application CAS configuration)	%windir%\Microsoft.NET\Framework\{version}\CONFIG

For more information about ASP.NET Web application CAS configuration files, see Chapter 9, "Using Code Access Security with ASP.NET."

Hierarchical Policy Evaluation

For centralized administration, settings can be applied in Machine.config. The settings in Machine.config define machine-wide policy and can also be used to apply application-specific configuration using <location> elements. Developers can provide application-configuration files to override aspects of machine policy. For ASP.NET Web applications, a Web.config file is located in the application's virtual root directory and optionally in subdirectories beneath the virtual root. Consider the arrangement shown in Figure 19.2.

Figure 19.2: Hierarchical configuration

In Figure 19.2, the AppRoot Web application has a Web.config file in its virtual root directory. SubDir1 (not a virtual directory) also contains its own Web.config file, which gets applied when an HTTP request is directed at http://AppRoot/SubDir1. If a request is directed at SubDir2 (a virtual directory) through AppRoot, for example, http://Server/AppRoot/SubDir2, settings from Machine.config and the Web.config in the AppRoot directory are applied. If, however, a request is directed at SubDir2 bypassing AppRoot, for example, http://Server/SubDir2, then only the settings from Machine.config are applied.

In all cases, base settings are obtained from Machine.config. Next, overrides and additions are applied from any relevant Web.config files.

If the same configuration element is used in Machine.config and in one or more Web.config files, the setting from the file lowest in the hierarchy overrides the higher-level settings. New configuration settings that are not applied at the machine level can also be applied to Web.config files and certain elements can clear the parent-level settings using the <clear> element.

The following table shows where the combined configuration settings are obtained from for a combination of Web requests that apply to Figure 19.2.

Table 19.2: Applying Configuration Settings
HTTP Request	Combined Settings Obtained From
http://Server/AppRoot	Machine.config Web.config (AppRoot v-dir)
http://Server/AppRoot/SubDir1	Machine.config Web.config (AppRoot v-dir) Web.config (SubDir1)
http://Server/AppRoot/SubDir2	Machine.config Web.config (AppRoot v-dir)
http://Server/Subdir2	Machine.config

<location>

The <location> element is used for three main purposes:
To apply configuration settings to specific application files.
To centralize administration by applying application-specific settings in Machine.config.
To lock configuration settings to prevent override at the application level.

The <location> tag can be used in Machine.config or Web.config. With Machine.config, if you specify the path , then it must be fully qualified and include the Web site name, virtual directory name, and optionally, a subdirectory and file name. For example:

 <location path="Web Site Name/VDirName/SubDirName/PageName.aspx" >   <system.web>    . . .   </system.web> </location>

Note	You must include the Web site name when using the location tag from Machine.config.

With Web.config, the path is relative from the application's virtual directory. For example:

 <location path="SubDirName/PageName.aspx" >    <system.web>    . . .    </system.web> </location>

Applying Configuration Settings to Specific Files

Use the path attribute to apply configuration settings for a specific file. For example, to apply authorization rules to the file Pagename.aspx from within Web.config, use the following <location> element:

 <location path="SubDirName/PageName.aspx" >   <system.web>     <authorization>       <deny roles="hackers" />     </authorization>     </system.web> </location>

Applying Application Configuration Settings in Machine.config

You can also apply application-specific settings in Machine.config by using <location> statements that specify paths to application directories. This has the advantage of centralizing administration. For example, the following fragment shows how to enforce the use of Windows authentication and prevent the use of impersonation in a particular application.

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

Locking Configuration Settings

To prevent individual applications from overriding machine-level policy configuration, place settings within a <location> element in Machine.config and set the allowOverride="false" attribute.

For example, to apply machine-wide policy that cannot be overridden at the application level, use the following <location> element:

 <location path="" allowOverride="false">   <system.web>      machine-wide defaults   </system.web> </location>

By leaving the path attribute empty, you indicate that the settings apply to the machine, while allowOverride="false" ensures that Web.config settings do not override the specified values. Any attempt to add elements in Web.config will generate an exception, even if the elements in Machine.config match with those of Web.config.