Interaction between URL Rewriter and Request Filtering Modules for IIS7
I hope folks have noticed the TP for the URL Rewriter module. Download it and give it a try!
Microsoft URL Rewrite Module for IIS 7.0 CTP1 (x86)
Microsoft URL Rewrite Module for IIS 7.0 CTP1 (x64)
I have been playing around with in my spare time to get a feel for it, and if you are not familiar with rewrite, stop by the walkthrough here.
While playing around with it an interesting question occurred to me ... how do the Rewriter module and the Request Filtering module interact with a request? I ask this question because if I block an HTTP request with a particular pattern in Request Filtering, and I attempt to rewrite the very same pattern to something else in the Rewriter module, who trumps who?
Expectation of a secure server
First let's figure out what we should expect to happen. Request filtering exercises a contract to look at requests coming to the server from the client, unadulterated. So if I have a rule that says disallow .aspx requests and a client types in the URL http://localhost/foo.aspx in his/her browser, the request should be blocked, period.
URL Rewriter module is a server-side request modification entity. So one should put it in the same bucket as an ASP.NET application that redirects or changes request parameters. So if I have a rewrite rule that changes the file extension of every request that ends in .foo to .aspx, it should not be considered a violation of the request filtering rule. The reason being that the client typed in http://localhost/xxxxxx.foo in his/her browser and since that does not have the .aspx extension, the request should be allowed to execute.
Behavior on IIS7
In a nutshell, IIS 7.0 is well behaved. In the request processing pipeline, the request filtering module gets a higher priority than the rewriter module. The rewriter module also has a sufficiently high priority in the request processing queue (otherwise it wouldn't be a very useful module), but it still kicks in after request filtering module on the BeginRequest path. The important takeaway here is that this is the desired order of processing, and so if you are manually tweaking module order and priority in configuration, swapping the order of these two could be considered as breaking the security contract that request filtering tries to establish, don't do it!
Bottom line, the defaults are good ... we have thought about things before putting them in order, even though it may look like a random ordering to the untrained eye :)