I have Request Filtering enabled in my IIS 7.5 and want to keep it that way, however, one site is basically just a proxy for some internal Java application and I'd like to disable Request Filtering for that site. Is it possible to do that?
3 Answers
You could enable Request Filtering for the top (server) level, and then just add a <clear />
in the individual sections in the web.config file for the site for which you don't want to use Request Filtering:
<configuration>
<system.webServer>
<security>
<requestFiltering>
<denyUrlSequences>
<clear />
</denyUrlSequences>
<fileExtensions allowUnlisted="true">
<clear />
</fileExtensions>
</requestFiltering>
</security>
</system.webServer>
</configuration>

- 25,161
- 4
- 63
- 95
-
1That is better than removing the rules one by one but still leaves request filtering active, i.e. you could see errors due to double escaping settings etc. I'd rather completely disable it to prevent any possible issues, is it doable? – Borek Bernard Feb 14 '12 at 00:51
-
Also add
to clear it completely. I had to do this to do a reverse proxy of OpenGrok serving .config files for example. – Wolf5 Jan 16 '17 at 15:18
Here's a different approach no one has suggested, and I've confirmed it works: You could remove the request filtering module, at the site level. That's what actually implements the feature. (In my testing, I've proven that doing this does disable the characteristics enabled via request filtering. That's of course something to be very cautious about doing. More on that at the end here.)
And you can remove the module either a) in the IIS UI (by going to the "modules" section for the site, finding the RequestFilteringModule in the list and clicking "remove" on the right) or b) in the web.config, by adding a "remove" element for that module. More on that in a moment.
But note that in either case, by default IIS is configured (for security reasons) to NOT allow you to remove this module--but it can be overridden. This is controlled by a line in the applicationhost.config file, which has an element:
<add name="RequestFilteringModule" type="" preCondition="" lockItem="true" />
which is located within the elements:
<location path="" overrideMode="Allow">
<system.webServer>
<modules>
Assuming you have the authority to change that file (and you should always be VERY careful about doing that), change that "true" to "false". If you had tried to remove the module in the IIS UI for the site, the error preventing that should no longer occur and the module would be removed. What the removal via the UI would do is create (or modify) the web.config file for that site to hold at least these elements:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<modules>
<remove name="RequestFilteringModule" />
</modules>
</system.webServer>
</configuration>
And that is indeed what you could do instead manually yourself, if you wish, by editing your site's web.config. Do be very careful when editing that file also. If there was already a web.config file for the site, and you wanted to add this "remove" of that module, you should first save a copy of it before attempting this modification. Then you would need to carefully fold those elements into that existing file. (And again, if you try to do this change manually, you still must set that lockitem="false"
element discussed above, to allow the removal to work.)
And upon saving such a change to the web.config, you should immediately check in the IIS UI by going to the modules section for the site, hitting the refresh button (top right of IIS) or hit f5, to confirm whether a) the module is removed or b) you get some error due to a mistake in your changing that web.config file--in which case undo the change or revert to the backup you took.
Finally, anyone considering this removal of the module (complete removal of "request filtering") from an IIS site should do so with careful consideration. It does add many protections, by default. One reason I wanted to do it was when I had a request failing with a 403. I couldn't readily tell what was causing it, and I suspected the request filtering (though normally it offers clear indications of its role in a rejection, at least if the request is made locally where IIS errors are set to show details by default.)
Anyway, I DID implement this removal, and again I DID confirm that one of the aspects it should have rejected (a request matching a filtering rule "deny path" I'd created) was now allowed, until I put the module back. In the end, it didn't help me: the 403 turned out to be due to the browser running on Windows 2008 and so was using SSL3, which the server (rather than IIS) was rejecting. Lesson learned. But it forced me to find this answer, and I wanted to share it if the OP is still seeking it.

- 240
- 3
- 9
Update in Dec 2022: please see a comment I added after my answer here, posted 3 years after I wrote this answer.
I'm surprised to see no answer to this here since 2012. There is indeed provision in IIS for removing a filter, but sadly not using the IIS UI (even in 2019 as I write). Instead, it can be done easily by carefully editing the site's web.config (or creating one if needed).
Briefly, a filter can be removed by modifying any isapiFilters element you may find (or by adding one if needed, see below), and then adding a single line "remove" element, naming the filter you want to remove,. Beware the filter name is case-sensitive.
Assuming you have a web.config with no isapiFilters elements already, you could add these lines to the file (again, pay attention to case of all three lines if you type rather than copy/paste), which would remove a filter named Bob:
<isapiFilters>
<remove name="Bob" />
</isapiFilters>
This would be found or placed one level inside of the system.webServer element, like is shown in the other answer here.
For some readers, that may be all they need to hear. Others could use more elaboration, and I hope to cover that in a blog post, whose link I'd come back here and add when I do it, including covering: all the lines needed if you have no web.config, what errors you may hit in trying this, and tips on implementing a change like this more safely.

- 240
- 3
- 9
-
ah, my bad. I see now (3 years after my answer here) that *I* was interpreting this differently than the asker: they were talking about the IIS security feature called "request filtering", whereas I was referring to IIS "isapi filters". Apologies. Anyway, I will leave this in case someone else may well find this looking for that (as I had, originally). – charlie arehart Dec 24 '22 at 06:37