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.

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.

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.

generic reparenting in Silverlight

If you have tried to detach an object from its parent in Silverlight you have undoubtedly discovered that this.Parent doesn't expose the Children collection and that most if not all of the code on the net requires knowledge of the type of the Parent. This inevitably leads to brittle code and introduces constraints on what type of container your control can be placed in.

Fortunatly .Net gives us a tool to write generic code in just this type of situation... reflection. So with that in mind I wrote a simple pair of functions that set or clear the parent of a Silverlight control as long as the Parent has a collection of UIElements named Children.

It should be possible to get rid of the (expensive) calls to MethodInfo.Invoke but as this code is code is called infrequently in my case I'm not that concerned with with the optimization. I'll leave it as an exercise to the reader to figure out this optimization if your use case is different.