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

Question

On my ASP.NET MVC application, I am trying to implement a URL like below :

/product/tags/for+families

When I try to run my application with default configurations, I am getting this message with 404.11 Response Code :

HTTP Error 404.11 - Not Found

The request filtering module is configured to deny a request that contains a double escape sequence.

I can get around with this error by implementing the below code inside my web.config :

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

So, now I am not getting any 404.11.

What I am wondering is that what kind of security holes I am opening with this implementation.

BTW, my application is under .Net Framework 4.0 and running under IIS 7.5.

Answer 1

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.