Protecting Resources in IIS

Here are some rules/methods regarding how to protect resources in IIS 6.0 (adopted from Michael Volodarsky's article Are You Protected? Design and Deploy Secure Web Apps with ASP.NET 2.0 and IIS 6.0:

• If your application is programmatically accessing data or supporting files during its execution, you should place them outside the Web namespace.
• If you cannot remove all such files, make sure that IIS is configured not to serve these files to Web clients. This should be accomplished by mapping the extensions for the protected files to ASP.NET in the IIS script processor map configuration, and subsequently mapping those extensions to the HttpForbiddenHandler or HttpNotFoundHandler in the ASP.NET configuration for the application or directory. By default, ASP.NET already blocks access to a number of extensions common to Web applications, including .cs, .java, .mdb, .mdf, .vb, and others.
• If you use the IIS static file handler, you should also make the files hidden for additional protection because the IIS static file handler will not serve files that have been given the hidden attribute.

It is frequently thought that removing a corresponding extension entry from the IIS MIME mapping configuration will prevent the static file handler from serving files with that extension. In actuality this is not always true because the static file handler will also honor the registry MIME mapping configuration and therefore will still serve the extension if the registry entry is present. Because of this, you would have to make sure that both the metabase MIME mapping configuration and the registry key in HKEY_CLASSES_ROOT do not contain an extension entry for the forbidden extension. Due to the management complexity, this practice is not recommended as a way of securing content.

Of course, this guidance regarding the IIS static file handler only applies to extensions that are not mapped to an ISAPI extension in the IIS script mapping configuration.