Tuesday, September 28, 2010

Script Resource filter up on codeplex

I pushed a ScriptResource wrapper yesterday that implements white list based filtering for Script Resources. This module also contains some defense against the padding Oracle... which is obviously no longer relevant.

Tuesday, September 21, 2010

blocking requests to sensitive files (e.g. web.config) through *.axd requests

After Doug's comment yesterday I started poking around to see if there was a to filter requests to sensitive files and as it turns out the answer is yes.
Both WebResource.axd and ScriptResource.axd using the function Page.DecryptString which is marked as internal. We can, of course, use reflection to get access to this function and evaluate the decrypted string that the user is trying to pass to these these classes. The updated code below includes code to do just that and passes each string to a blacklisted set of regular expressions.
Important: You also need to rewrite requests to ScriptResource.axd into this module.

Ideally the list of expression would be loaded from web.config, but for the time being you will need to add any additional expressions in the constructor.

Monday, September 20, 2010

My workaround for the ASP.Net Vulnerability

So over night I hacked together a quick work around that I think (No waranty, YMMV, and all that) will help with this advisory from Microsoft.
The vulnerability seems to rely on getting different responses for different errors with a potential second gen attack using timing information to glean the same information (albeit more slowly) from requests toWebResource.axd. I attempt to work around both of these here.

The first thing you are going to need is a custom HttpHandler, which we are going to use to wrap requests to WebResource.axd
here is the code:
Basically this looks for the two exceptions in question and throws a 404 for either one. Since this is only for embedded resources I don't think this will cause a problem for AJAX in most cases, but if so you could probably figure out a carve out that would leave them working.

the next thing we need to do is to wire up our handler to some arbitrary file extension in your web.config (see below)
Now we just need to get IIS to route requests through our fixed handler and were done. I used the URLRewrite module found here and mapped WebRequest.axd to the new URL that I attached my handler too.




feedback welcome.