Is Enabling Double Escaping Dangerous

Is Enabling Double Escaping Dangerous?

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.)

Asp.Net MVC Core enabling double escape

ASP.NET Core application could be hosted on variety of web servers (IIS, Kestrel, Nginx, Apache, ...). All these web servers know nothing about request filtering (and particularly enabling of double escape) which is a native IIS feature. It's a hosting concern and ASP.NET Core application should not deal with it directly. If URL like http://youserver.com/Home/Phone/+12345 will reach ASP.NET Core pipeline, plus sign will not be treated in any special way and will get to string model as + character.

When you host your application on IIS, web.config is still in use, so you could configure <requestFiltering allowDoubleEscaping="true"/> as for usual ASP.NET application. Again, you should not be afraid that you do something in non ASP.NET Core way. You configure a hosting concern; it's not the field of ASP.NET Core.

If you want to host application in another Web server, you should check how it handle special characters. I know that Kestrel will just pass such URLs as is, so you don't need to take any specific actions if hosted on Kestrel.

double escape sequence inside a url : The request filtering module is configured to deny a request that contains a double escape sequence

The security holes that you might open up have to do with code injection - HTML injection, JavaScript injection or SQL injection.

The default settings protect you from attacks semi-efficiently by not allowing common injection strategies to work. The more default security you remove, the more you have to think about what you do with the input provided through URLs, GET request querystrings, POST request data, HTTP headers and so on...

For instance, if you are building dynamic SQL queries based on the id parameter of your action method, like this:

public ActionResult Tags(string id)
{
    var sql = "SELECT * FROM Tags Where tagName = '" + id + "'";
    // DO STUFF...
}

(...which is NOT a good idea), the default protection, put in place by the .NET framework, might stop some of the more dangerous scenarios, like the user requesting this URL:

/product/tags/1%27;drop%20table%20Tags;%20--

The whole idea is to treat every part of urls and other inputs to action methods as possible threats. The default security setting does provide some of that protection for you. Each default security setting you change opens up for a little more potential badness that you need to handle manually.

I assume that you are not building SQL queries this way. But the more sneaky stuff comes when you store user input in your database, then later displaying them. The malevolent user could store JavaScript or HTML in your database that go out unencoded, which would in turn threaten other users of your system.

Why might I get a double escape sequence error in mobile chrome but not desktop chrome?

I made a mistake and forgot about a function that added +1 to the front of user's phone numbers, which were later used in constructing the URL. The + character is what causes IIS to throw the double escaping error (More info here and here). Once I remove this + character, the error no longer shows up. This error wasn't present in the desktop version because I manually entered the URL and did not add a + character when testing.

Will url encoding make IIS 7 accept urls that originally contains a double escape sequence?

Unfortunately it won't. IIS7 will decode your URL, see that you were encoding a plus sign, and then still throw the double escape sequence error. If you really want to use plus signs I think you have to allow double Url encodings.

Here is a blog post from a developer on the IIS team detailing some reasons why they chose to not not allow '+' signs to be accepted.

Another option, and you may have thought of this, is that you could come up with your own escape sequence to replace plus signs with that IIS won't recognize. Then you would need to write your own code to check for your escape sequence and rewrite it to a '+'.

If you want more detail on how the entire check system works in IIS7 and ASP.Net you can see my answer to a similar question here.

Hope this helps.

How to encode IP for GET request in api in .NET

Try to encode it in base 64. You can find how to do it here

/api/endpoint/MTIuMTIuMTIuMTI=

---

Related Topics