Is Enabling Double Escaping Dangerous?

Question

I have an ASP.NET MVC application with a route that allows searching for stuff via /search/<searchterm>.

When I supply "search/abc" it works well, but when I supply "/search/a+b+c" (correctly url encoded) then IIS7 rejects the request with HTTP Error 404.11 (The request filtering module is configured to deny a request that contains a double escape sequence). FIrst of all, why does it do this? It only seems to throw the error if it is part of the URL, but not as part of a query string ( /transmit?q=a+b+c works fine).

Now I could enable double escape requests in the security section of my web.config but I'm hesitant to do so as I don't understand the implications, and neither why the server would reject the request "a+b+c" as part of the URL but accept as part of a query string.

Can someone explain and give some advice what to do?

Answer 1

I would just like to add some information to Eamon Nerbonne's answer related to the "what to do" part of your question (not explaining the whys).
You can easily change a particular application's settings too with

1. opening the console with admin rights (Start - cmd - right click, Run as administrator)

2. typing in the following (taken from here: http://blogs.iis.net/thomad/archive/2007/12/17/iis7-rejecting-urls-containing.aspx):

   %windir%\system32\inetsrv\appcmd set config "YOURSITENAME" -section:system.webServer/security/requestfiltering -allowDoubleEscaping:true
   

   (you can e.g. substitute YOURSITENAME with Default Web Site for applying this rule to the default website)

3. Enter, ready.

An example:

1. firstly I had the same problem:
2. Typing in the text mentioned above:
3. Now it works as expected:

Answer 2

Have you thought about having the search URL like '/search/a/b/c'?

You'd need to setup a route like

search/{*path}

And then extract the search values from your path string in the action.

Answer 3

I ran into this under IIS 7.5 doing a Server.TransferRequest() in an application.

Encoding the filename caused the double-escape problem, but if I didn't encode it then I'd run into the "potentially dangerous Request.Path" error.

Putting an any protocol, even an empty one, on the URL I pass to Server.TranferRequest() fixed the problem.

Does not work:

context.Server.TransferRequest("/application_name/folder/bar%20bar.jpg");

Works:

context.Server.TransferRequest("://folder/bar%20bar.jpg");