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?

I also tried the possibly more correct option of calling Server.Url*Path*Encode and ended up with `/search/a%2520b%2520c` in the mark-up which led to a lovely "A potentially dangerous Request.Path value was detected from the client (%)" error. You can't win it seems. — Zhaph - Ben Duguid, May 12 '11 at 23:28
Encoding before the ? in a URL is different than after the ?. Before the ?, use URI Percent Encoding which encodes space as %20. After the ?, use "application/x-www-form-urlencoded" encoding which encodes space as +. So "/search/a+b+c" is not correctly encoded, but "/transmit?q=a+b+c" is correctly encoded. — user281806, Jan 13 '22 at 20:58

score 172 · Accepted Answer · edited Feb 15 '18 at 22:24

172

Edit: Added emphasis to relevant sections.

Basically: IIS is being excessively paranoid. You can safely disable this check if you're not doing anything particularly unwise with the uri decoded data (such as generating local filesystem URI's via string concatenation).

To disable the check do the following (from here): (see my comment below for what double escaping entails).

<system.webServer>
    <security>
        <requestFiltering allowDoubleEscaping="true"/>
    </security>
</system.webServer>

If the plus symbol is a valid character in a search input, you will need to enable "allowDoubleEscaping" to permit IIS to process such input from the URI's path.

Finally, a very simple, if limited workaround is simply to avoid '+' and use '%20' instead. In any case, using the '+' symbol to encode a space is not valid url encoding, but specific to a limited set of protocols and probably widely supported for backwards-compatibility reasons. If only for canonicalization purposes, you're better off encoding spaces as '%20' anyhow; and this nicely sidesteps the IIS7 issue (which can still crop up for other sequences, such as %25ab.)

edited Feb 15 '18 at 22:24

t3chb0t

16,340
13
78
118

answered Sep 21 '09 at 07:43

Eamon Nerbonne

47,023
20
101
166

3

I'd disable the check. It's a hassle and doesn't provide extra security to most apps. – Eamon Nerbonne Sep 21 '09 at 08:03
3

Do you have a link/reference that it's pretty much safe to disable double escaping? Also, what exactly does this security measure prevent from happening? – Alex Sep 21 '09 at 08:04
15

If a uri is double-escaped, then the unescaped uri components may themnselves contain reserved characters and thus (parts of) the unescaped uri may itself be a valid uri. In short, if you use the unescaped uri string to construct new uri's - in particular filesystem paths - and you fail to correctly escape the new path, you may allow path injection. Path injection could allow an attacker to trick your program into processing data it shouldn't, or into confusing it into thinking two uri's are different when they are actually identical but simply encoded differently. – Eamon Nerbonne Sep 21 '09 at 08:21
2

http://blogs.iis.net/thomad/archive/2007/12/17/iis7-rejecting-urls-containing.aspx – VdesmedT May 03 '13 at 09:56
1

@EamonNerbonne if the URL is `/foo/bar+baz.jpg` with `/foo` being a Virtual Directory in IIS mapped to a network share and `bar+baz.jpg` being the file name, is it then safe to do this? – user247702 Jul 29 '14 at 07:09
4

@Stijn: **Yes: that's safe**. All this check does is filter out requests that might possibly be misinterpreted by buggy code (esp if you double decode or build Uri's via string-concat and without proper encoding). You're not doing any kind of processing whatsoever, so that's pretty much automatically safe on your part. Any bug would need to be in the basic file serving code of IIS, and I think we can safely assume that's been very, very thoroughly battle tested by now. Again, this check is nothing fancy, it just bails on things that might be *decoded* and then look like an *encoded* uri. – Eamon Nerbonne Jul 29 '14 at 10:03
This just caught me using international mobile phone numbers as keys. eg +61421123456. Thanks for the answer. – Hecatonchires Jun 07 '19 at 01:10
You can also get this problem with an email address if people use the `+` symbol (officially supported by gmail) to make 'throwaway' addresses. – Simon_Weaver Jan 06 '20 at 19:51

score 2 · Answer 2 · edited May 23 '17 at 12:26

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

opening the console with admin rights (Start - cmd - right click, Run as administrator)
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)
Enter, ready.

An example:

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

score 1 · Answer 3 · edited May 17 '22 at 21:29

1

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.

edited May 17 '22 at 21:29

ΩmegaMan

29,542
12
100
122

answered Sep 21 '09 at 07:58

Charlino

15,802
3
58
74

The problem is that other URL encoded characters (including '/' itself) could be part of the search. – Alex Sep 21 '09 at 08:04
Could you not encode all the '/' that are actually part of the search to '%2F'? – Charlino Sep 21 '09 at 20:55

score 0 · Answer 4 · edited May 23 '17 at 12:26

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");

Is Enabling Double Escaping Dangerous?

4 Answers4

Linked