ASP.NET ValidateRequest is a security mechanism designed to prevent cross-site scripting attacks in ASP.NET applications. It looks at data in the HTTP request parameters, and issues an error if it finds anything that is “suspicious”. And, for the most part, it works fine. But, like many security technologies, there are two big problems – false positives and false negatives. First off, let’s take a look at how ValidateRequest works. Using the .NET Reflector tool, we can see the attack detection algorithm in the IsDangerousString method of the CrossSiteScriptingValidation class, which is the crux of the ValidateRequest functionality:
This method looks for either a less than or ampersand character in the string. If one exists, it first checks to make sure it is not the last character (I’m not entirely sure why, but it seems this would only allow fairly benign strings). Then, if the offending character is a less than character, the method checks if the next character is a letter, an exclamation point, or a forward slash. If so, it is considered dangerous. Also, if the offending character was an ampersand, and the next character is a hash mark, the string is considered dangerous. This algorithm iterates through the string, stopping at each instance of one of these symbols.
Now that we have a good idea how this functionality works, let’s examine why it isn’t always ideal.
False Positives
ValidateRequest looks for anything that resembles HTML that code be used to execute script. Unfortunately, the detection technique can be a bit trigger-happy. Some strings that appear to be malicious are perfectly normal and expected. Examples:
- Rich text controls often use HTML characters for markup.
- XML in AJAX calls has been known to trip the ValidateRequest error.
Many people advise turning ValidateRequest off at the first sign of problems. The first Google hit for ValidateRequest is a link to an article from 2004 titled “Surviving ValidateRequest” discussing why it’s not always in a developer’s best interest to use the mechanism (although it does discuss the threats and countermeasures regarding cross-site scripting in the article as well). Here’s a quote:
“Another problem with ValidateRequest set to true is that it is a rather broad and stupid protection, erring on the side of catching too much rather than letting something dangerous slide by.”
OK, fair enough, simply disable ValidateRequest when it causes problems, and figure out how to prevent XSS by yourself in those cases. But something so strict that it chokes on regular input has got to prevent all bad input, right?
False Negatives
No one claims that ValidateRequest is perfectly effective in stopping cross-site scripting attacks. But what does it miss? From a recent blog post:
“ValidateRequest may miss some crafty inputs.”
Well, what are these “crafty” values? One is mentioned in the article – an exploit which is mentioned in the Microsoft Security Bulletin MS07-040.
There is another, perhaps more common (and still unpatched) form of XSS which isn’t stopped by ValidateRequest. It is known as HTML Attribute-Based Cross Site Scripting, according to Jeremiah Grossman. The attacker uses an HTML attribute to insert an event handler that causes a script to run.
ValidateRequest doesn’t even attempt to look for this – there are no angle brackets required.
For example, take the following ASP.NET code:
[MISSING IMAGE]
This code is used to display a page which renders a link to an article on Wikipedia.
[MISSING IMAGE]
We can enter this value:
[MISSING IMAGE]
This will cause the following HTML to be rendered:
[MISSING IMAGE]
So we have caused cross-site scripting in spite of ValidateRequest being enabled. This is due to the fact that not all cross-site scripting attacks require the use of less than or ampersand characters. For example, consider what would happen if a parameter value was echoed directly in JavaScript (this can happen in AJAX apps). The results can be scary!
ValidateRequest is not a panacea. Instead, consider augmenting the functionality with stronger protection afforded by the Anti XSS library, and as always, implement and enforce strict validation.
