Security Hole In ASP.NET Beta 1
Jonathan Goodyear, MCSD, MCP, CLS
4/30/2001

Background
In the Beta 1 version of the .NET Framework, configuration settings for ASP.NET web applications are kept in an XML formatted file named config.web. There is one config.web file at the machine level, with the option of having copies with overriding settings in any directory of your web application. Settings in a config.web file cascade to all sub-directories in your web application, unless overridden by another config.web file.

For Beta 2, Microsoft changed things around. ASP.NET settings at the machine level will now live in a file named computer.config, while settings at the web application level will be contained in files named web.config. Microsoft is encouraging the use of the ".config" file extension for XML based configuration files; Even those that are custom built. Some examples of this are the portal.config file used in the IBuySpy Portal Application, and the ezine_settings.config file used in the eZine.Framework upon which the angryCoder site is built.

The hole
The security hole comes into play due to the fact that the new naming convention for XML based configuration files didn't come about until after Beta 1 was released. This means that the default ASP.NET settings allow files with the ".config" extension to be browsed as clear text. I was made aware of this situation when an angryCoder reader (luckily an honest one) emailed me my user name and password that he had obtained by navigating to my ezine_settings.config with his browser. One of the disadvantages of giving away the source code for the eZine.Framework is that aspiring hackers have a convenient roadmap of my entire site. It gave me a rather unsettling feeling in my gut to find out that I had been careless enough to leave my site so exposed.

The fix
There are two bright spots to this security hole. First, it is limited to Beta 1 because files with the ".config" extension will be guarded by default in Beta 2. Second, there are two different, yet equally easy, fixes for the hole that you can implement right now.

The first fix option is the one that the IBuySpy Portal Application implemented. They placed their portal.config file in a directory that the anonymous user account does not have "read" privileges for. Using this method, their business logic components can still import and use the XML settings in the file, while keeping it from the prying eyes of hackers.

the second fix option is the one that I implemented for angryCoder. The first step is to open up the Internet Services Manager MMC Snap-In and configure files with the ".config" extension to be handled by the ASP.NET ISAPI Application. You do this by right-clicking your web application, and choosing the "Properties" menu option. Then, select the "Home Directory" tab, and click the "Configuration Button". The "App Mappings" tab of the Application Configuration screen should now be showing. Click the "Add" button. On the dialogue that pops up, browse to the C:\WINNT\Microsoft .NET\Framework\v1.0.2204\ directory and select the xspisapi.dll file (hint: you'll probably have to click the "Files of type" drop-down and select "Dynamic Link Libraries" to make the file browsable). After you've selected the xspisapi.dll file, enter ".config" in the "Extension" box, then click the "OK" button. Click the "OK" button again at the Application Configuration screen, and again at the web application properties screen.

Now that you've told IIS that the ASP.NET ISAPI application should handle files with the ".config" file extension, the next step is to tell your web application what, specifically, to do when a user browses to one of these files. This entails a