ASP.NET 2.0 Configuration Lockdown

Hundreds of significant improvements have been made inASP.NET 2.0, many of which help improve security. One of these improvementsthat has not received much attention (as of yet) are new options foradministrators to lock down the ASP.NET configuration.

Microsoft s documentation and white papers always refer toWeb hosting services when describing these features. As a result, you may haveignored them because you don t run a Web hosting service. They are actuallyquite useful in other environments, as well. They can be a boon to anyonewanting to delegate portions of the administration of an application server,while still maintaining security control. They are also highly useful in ensuringpolicy compliance, preventing configuration errors, and otherwise maintainingcontrol over your Web server s behavior.

Most ASP.NET applications are deployed on Web servers side-by-side with other applications. A contentmanagement system, search function, and administration tools could all beseparately developed ASP.NET applications that work together to form the entireWeb site. In such an environment, some configuration settings will be sharedand some will be unique to each application.

In corporate environments, these applications are oftendeveloped and deployed by different departments or groups. By locking down theASP.NET configuration, the Web server administrator can ensure that all groupschoose only secure configurations for their applications, while still allowingthem freedom to configure non-security-relevant settings. Corporate policy forsecurity and non-security settings can also be enforced centrally, ensuringcompliance.

Background: ASP.NET Configuration

A review of the ASP.NET configuration system will behelpful to understand these options. Each application can have a web.configfile, which specifies (using XML) the configuration settings for thatapplication. Any settings not specified explicitly are inherited from thesettings specified in the directory above. (Note that this inheritance is doneusing Web server virtual directories, not physical directories.)

At the top of the inheritance hierarchy is a central copyof web.config stored in the CONFIG subdirectory of the .NET Frameworkinstallation. Any settings not specified here will use default values codedinto the framework. Normally, the settings in the framework directory are thesole province of the administrator of the system, since they can potentiallyaffect every .NET application on the system. Conversely, the settings in anapplication s web.config are the province of the administrator of thatapplication, and can only affect it and its subdirectories.

Configuration files contain many critical settings,including how authentication and authorization is handled, choices forcryptographic algorithms and keys, and sometimes even the credentials ofadministrators. It is important that control is maintained over these settingsso that incorrect choices are not made. Poor choices within an individualapplication could compromise the security of the entire Web server.

The system administrator can set defaults based oncorporate policy in the upper web.config files. But there must be a way toensure that these choices are not altered within the local configuration of anindividual application, in defiance of policy.

And indeed, ASP.NET 1.1 provided a means to do this. Thisis handled by the configuration element named , which istypically used as shown in Figure 1.

Figure 1: SampleASP.NET tag.

Elements specified inside a element willapply only to the resource (a directory or individual file) specified in thepath attribute. In the example in Figure 1, the application directoryMyApplication has been locked to run at Medium trust. If that application hasthe element in its web.config, an exception will be thrown whenthe application starts and it will not run.

There are a number of problems with this scheme. Theybecome immediately obvious to anyone who has tried to use it on a server withmore than a handful of Web applications present.

First of all, it clutters the central configuration filewith settings that are specific to an individual application. This breaks themodularity of the configuration system, and prevents some uses of the so-calledXCopy deploy. Each time the application is redeployed using XCopy, the system administrator often must tweak the centralconfiguration file to ensure settings are correct. This creates workflow issuesthat hamper your ability to delegate administration of the server.

Second, the semantics of the element, asa wrapper around the section-level element, causes problems. There are oftendefault settings for each section expressed in the central web.config. Theapplication-specific locks on these settings reside in a different spot in thefile, in order to obey XML syntax. This forces you to look at several spots inthe same file to get a full view of what the default for a given setting mightbe.

Third, this mechanism works only at the element level inXML, and does not offer attribute-level flexibility. Most configuration itemsin ASP.NET have many significant attributes, some as many as a dozen. If thesystem administrator locks an element in this way, the applicationadministrator cannot alter any attribute on the affected element. An examplewill help illustrate.

Suppose corporate policy dictates that forms-basedauthentication only is used over SSL secured links, and that the authenticationtimeout be set to a maximum of 10 minutes. An administrator might try toenforce this policy using the settings found in Figure 2. They would quicklyfind that this does not work as expected.

Figure 2:Enforcing forms policy incorrectly.

You will notice that no path attribute is specified on thelocation element in Figure 2, which causes these settings to apply to all applicationson the server. The problem is that there are about a dozen other attributes ofthe element, some of which are very application-specific, such asthe location of the login form. All of those very application-specificattributes would have to go into the central configuration file in order forany part of it to be locked. This further exacerbates the modularity issuementioned earlier.

.NET 2.0 Improvements

The designers of the .NET Framework were clearly aware ofthe limitations of the location element in .NET 1.1, and have added somesignificant new functionality in 2.0 to overcome these problems. The newfunctionality takes the form of new attributes that are inherited by allsection elements in the .NET configuration schema. The new attributes arelisted in Figure 3.

configSource=stringlockItem=BooleanlockAttributes=stringlockAllAttributesExcept=stringlockElements=stringlockAllElementsExcept=string

Figure 3: NewAttributes in .NET 2.0.

If you ve ever edited your web.config using Visual Studio2005, you may have noticed these attributes in the IntelliSense dropdowns.

The configSource attribute allows you to redirect anelement to be drawn from a separate file, much like the file includefunctionality of many programming languages. The string value, of course, is afile name. This can be useful as well in delegation of administration,particularly if you need to sub-delegate some configuration issues within agiven application. The way to implement this is to put the delegated configurationitem in a separate file, and refer to it in the main web.config usingconfigSource. Then, set the file system Access Control Lists (ACLs) to allowthe appropriate persons or roles write access on each of the files. The rest ofthis article, however, will focus on the other attributes, the ones that beginwith lock.

The lock attributes are the most interesting, and ingeneral do exactly what their names suggest. Use lockItem to lock the currentelement and all of its children. Use lockAttributes or lockAllAttributesExceptto lock specified attributes of the current element. Use lockElements orlockAllElementsExcept to lock specified sub-elements of the current element. Otherthan lockItem, each of the attributes expects a comma-separated list of attributenames in its value.

There are a number of advantages to using the new lockattributes to secure your configuration. For one, you specify these directly onthe element you wish to lock, and no longer have to use the enclosing locationelement. This makes the syntax for locking down an element much simpler in thecentral web.config. It also means you can specify default values that can beoverridden, and default values which are locked, all in one place. Properlyused, these attributes should reduce the clutter in your central web.configfile.

Practical Examples

Some practical examples will help illustrate. First, letus correctly solve the problem shown in Figure 2. The new configurationelements would look like that shown in Figure 4.

Figure 4:Enforcing forms policy correctly.

Notice that the location element is no longer needed. Simplyspecify the elements and attributes desired and indicate which attributes tolock. All other attributes are open to change by the application administrator.Meanwhile, we can rest easy that timeouts and SSL will be configured the waycorporate policy dictates.

A second example concerns modules and handlers. ASP.NETuses plug-in style architecture to add functionality to the framework. Two ofthe main places these are loaded are via the httpHandlers and httpModuleselements in the configuration. There are many cases where an individualapplication might load an extra handler or module to achieve somefunctionality. For example, many URL redirection libraries for ASP.NET take theform of loadable httpModules.

In most cases, however, you should not allow applicationsto remove functionality from the initially loaded set. You may have a moduleloaded that provides essential security or logging functions, which you do notwant disabled. Removing the HttpForbiddenHandler from a file extension like*.cs could cause the source code of your application to be disclosed to Website visitors.

Like many other list elements in web.config, these twosections use sub-elements named add , remove , and clear to manipulate thelist. To prevent removal of any of the stock handlers or modules, you shouldlock out use of both clear and remove . The syntax is shown in Figure 5.

Figure 5:Preventing removal of handlers and modules.

Implementing on a Production Server

You can lock down your server configuration by editing thetop-level web.config. Take care when editing this file, as careless errors cancompletely disable ASP.NET on the server. It is always best to experiment in atestbed environment before rolling out changes.

You will notice that while in ASP.NET 1.1 most defaultswere explicitly specified in the central configuration, this is not true inASP.NET 2.0. Many elements of the configuration obtain their defaultsinternally and do not exist by default in the central web.config.

In cases like this, you will have to add the appropriateXML to your central web.config, making your chosen defaults explicit. Often thesyntax to express the framework defaults is included in the relevant MSDNarticle. Make sure you put it in the appropriate point in the XML hierarchy ofweb.config; most settings reside inside the system.web element. Alter thedefault values to express your corporate policy, thenadd the attributes you need to lock each section.

When testing, watch for telltale configuration errormessages. This exception occurs before any of the application code executes,when the web.config is initially parsed. Figure 6 shows what the standardASP.NET error message shows when an attempt to unload a module has been blockedusing the example shown earlier.

Figure 6: Locked configuration errormessage.

Be aware that changing the defaults for some settings cancause particular applications to malfunction. Thorough testing is alwaysrecommended.

One limitation of the lock attributes will become obviousas you make changes. When you lock a setting, any attempt to touch thatsetting, even to set the same value as the locked one, will cause aconfiguration error. So in the process of locking down your server, you mayhave to scrub your applications web.config files of any reference toattributes that you are choosing to lock.

Of course, it is implied that if any effort to touch alocked setting will fail, an application cannot choose a more restrictivesetting than the one that is locked by the administrator. For example, if youhave locked all applications to Medium trust, an individual application cannotput itself on Low trust. Any override of a locked setting must be done usingthe location element in the web.config where it is locked. Consider the exampleshown in Figure 7.

Figure 7: Lockingdefaults and overriding for one application.

In Figure 7, forms authentication policy has been set for10-minute timeouts and SSL only, and the defaults are locked. However, thispolicy is overridden for a single application named Special . Otherwise,applications will not be allowed to alter these defaults. Note that it is notnecessary to specify the lock attributes on the location override, they stillapply from the default.

When choosing which elements to lock down, carefullyconsider your corporate policies and the various best practices documents onASP.NET. The Patterns & Practices section of MSDN has many documents thatmake excellent suggestions. Again, every configuration change has implicationsin the behavior of your applications, so you should read the guidelinescarefully and always test, test, test.

As a quick reference, Figure 8 shows a list of top-levelelements within that are worth considering locking forsecurity reasons.

Figure 8: ASP.NET configurationelements to consider locking.

The new locking elements in .NET Framework 2.0 provide anexcellent way to control the configuration of your Web server, while stillallowing administration of individual applications to be delegated to others. Theyavoid the pitfalls of the location tag from earlier versions of .NET, and allowyou a great deal of granularity and control.

With that said, these locking controls are by no means asecurity panacea. All deployed Web applications should be carefully audited forconfiguration errors and other security problems, as part of your securedevelopment lifecycle.

But locking down critical configuration items centrallyprovides an additional safeguard and becomes part of your defense-in-depthstrategy. This is an excellent tool for any ASP.NET administrator to have intheir toolbox.

Tim Farley is asenior software engineer for SPI Dynamics and a researcher for the company srenowned R&D team, SPI Labs. Tim is responsible for researching newtechniques to secure Web applications as they are developed and deployed. Timcame to the IT security industry via his expertise in reverse engineering ofsoftware, which he has been doing for over 20 years. He is a published author,has contributed code to open source software projects, and has participated instandards committee work with the IETF. Tim has also testified as an expertwitness on reverse engineering in Federal court.