MSI Released for ASP.NET Vulnerability

Last Tuesday I posted about a potential vulnerability in ASP.NET along with some code to plug the hole. Two days later, a Microsoft Installer package was released which contains the ValidatePath HttpModule. This is a more thorough, easier-to-manage, and easier-to-deploy solution for the canonicalization issue.

While the vulnerability affects IIS 5.x and IIS 6.x should (in theory) be safe by the nature of its differences, Microsoft is recommending that this HttpModule be installed on all ASP.NET installations, 5.x and 6.x alike. Unlike the global.asax fix, this HttpModule is installed and referenced in machine.config and will secure all virtual servers and applications on the server against the vulnerability.

Are you at risk? I promised more detail on that, so here's what you need to know:

Let's call the web.config file in your application root your "primary web.config." The vulnerability outlined in the original NTBugTraq report describes an attack where a web.config located in a subfolder (call it a "secondary web.config") might not be processed. Therefore, if your secondary web.config contains more stringent security than in the application root, that extra security could be bypassed with a malformed request.

As far as I understand it, the primary web.config in the application root is always processed. If you define security and subpaths there, you're in good shape. The potential vulnerability is with subfolders which use a secondary web.config.

I don't know of any Microsoft server applications whose out-of-the-box deployment can be compromised by this method (SharePoint, BizTalk, Outlook Web Access, MCMS). But forget that, just deploy the fix. If you run Reporting Services on the same box, you will require additional steps.

A lesson to take from this is that whenever possible, deploy your administration UI in a separate application with either a separate host header (e.g. http://admin.myapp.com/) or a secondary port (e.g. http://myapp.com:2112/). On IIS 6 this also allows you to assign a separate Application Pool running under a different identity than the public site, with Anonymous access turned off, and even to assign a set of acceptable incoming IP addresses for administration of your app. These are more easily set with the IIS UI than in code.

Also, calls to retrieve data from a database should do an authorization check against the identity of the current user, or the table structure should be such that you can assign rights to data so that either a Username or Group Name may be derived from the current Principle Identity and used as a parameter in the query. In other words, be sure that the current user has rights to data before returning it. Don't assume that since a user can see a page that they should be privy to the content it serves. The can here ends at authentication, the should is the part where an authorization check happens. A good security strategy actively employs both.

Finally and most obvious, don't hardcode sensitive information in your web page source, either in the .aspx or the code-behind files. While code-behind is not at risk here, hardcoded html in subfolders which meet the criteria may be at risk.

The two previous paragraphs are no longer just good design. In companies working to comply with the Sarbanes-Oxley Act, they represent an absolute minimum. If you've been resisting, it's time to step up your game. In the meantime, go install the fix and secure your sites.