Somebody brought up a good point about my Configuration Settings class today that I failed to mention in the article: Security requirements for an ASP.Net application to be able to actually make changes to the .Config file.

If you are running in the default security environment the ASP.Net app runs under the ASPNET or NETWORK SERVICE account and these accounts usually don't have rights to write to web.config or any other part of application.

I personally run my ASP.Net apps under a specific user and assign this user to a Windows 2003 Application Pool which I then use for the application. Usually I configure this user to have read/write access in the application directory because I have a number of tasks that read and write to the file system in various places of my framework. I don't feel this is a huge security risk because in order to do anything with these 'loose' permission soembody has to first be able to compromise either my app (via some script or injection) or by hacking into the machine itself. If that's the case my Web directory is probably the last thing I need to worry about.

So, by default ASPNET and Network Service aren't allowed and if you're not comfortable with the environment I run (and many aren't ) you can limit your exposure by just allowing read/write access to web.config for these accounts. This file already has read access (although it can't be accessed over the Web due to ASP.Net's internal forbidden handlers) which if anything is the bigger vulnerability.

Using Impersonation in a separate web.config
As I was thinking about this I found another solution that should work without changing security if you have a separate directory to run all Admin requests through. Updating web.config should not be something you do frequently, so this requirement to run from a separate directory should be workable - all my apps use an Administration path for all admin tasks for example and I can place a separate web.config there that uses Impersonation to run under the account the user logged in under.

In this admin directory which should sit below your app root you can add a secondary web.config file that overrides the security settings of the primary web.config file. Set it to use Windows Auth and Impersonation like this:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.web> 
    <identity impersonate="true" />
    <!-- WS: Allow only Authenticated users -->
    <authorization>
        <deny users="?" />
    </authorization>
 </system.web>
</configuration>

This is basically telling ASP. Net to impersonate the logged on user and to deny anonymous access which will force a login when any page in the directory with this web.config (or below) is accessed. Now when you hit any pages in the admin directory the remote user is impersonated and if this remote user has the appropriate rights on the server the application has rights to write web.config. This means an anonymous user has no access, but I as an Admin user have the rights to actually write to the .config files.