Is it harmful to allow http requests with very long querystrings in IIS?

Question

I am developing a website with a search feature that could generate HTTP requests that are very long (up to 15,000) characters. However, IIS has a default limit of 2048 characters for querystrings. This can be easily changed in a web.config file using the settings listed below.

system.web > httpRuntime > maxRequestLength
system.web > httpRuntime > maxUrlLength
system.webServer > security > requestFiltering > maxQueryString
system.webServer > security > requestFiltering > maxUrl

My question is whether there are any security concerns that I should be aware of if I allow very long querystrings in HTTP requests?

Update: I should add a few bits of info.

• The website will only be available to paid users who have signed into the website.
• The likelihood that anyone would create a search with more than 2048 characters in the url is VERY slim, but theoretically possible.

Answer 1

15,000 character URLs isn't going to work very well cross-browser: https://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url

Assuming you already know that, in an ASP.NET application, a 16,000 character limit will increase your vulnerability to request-queue-buffer exhaustion attacks 8x. Now, 8x is not that significant compared to better DoS attacks generally open on an ASP.NET website.

Regular expression matching is not probably a big issue. Most regexp attacks work equally well with 64-character and 64,000 character strings - they exploit an exponential backtrack pattern, and your request timeout makes the URL length quite unimportant. On the upside, most of these kinds of issues will show themselves quickly in performance issues. Also, regexes generally are only applied to the path, not the querystring.

Path regexes are generally quite fast and usually exit the match at the first integer comparison, although there are exceptions.

If you raise the limit, just ensure all URL rewriting, routes, path matching, and pre-HandleRequest events are efficient, have fast exit paths, and don't do any high-latency work like disk or db access.

Answer 2

Disclaimer: Let me preface by admitting I am by no means an expert, but here is my two cents anyway.

The reason that you put limits on querystrings, in my view, is to avoid processing unnecessarily long strings for the app. For example, your app may have some very complex URL routing rules (say, in MVC3) that say, evaluate the string with a bunch of RegEx. For short strings, this is not a big deal, but it can get hairy if you are evaluating a big string. Other times, like in your case, you might need to take that query string and do something else with it, like a DB lookup, etc. These things can take time and resources and potentially put a big strain on your web server.

In your case, without knowing what the routing will do (ie how it handles the query string), it is hard to know what impact this would have. Lets say all your route did was send back the length of the querystring. Then of course this is not as vulnerable to a DDoS style attack as if you were to generate all permutations of that querystring. Those are extreme examples, but thing like search, db lookup, etc could pose real issues and you could be left vulnerable to DDoS.