ValidateRequest Property (XSS)
There is no doubt that while working with ASP.Net you have run into the ValidateRequest property for a web form. This is a feature that has been around since version 1.1. It prevents the server from accepting un-encoded HTML data, which can be used to exploit client-side attacks like Cross Site Scripting (XSS). The most common example of cross site scripting is to enter <SCRIPT>alert(‘exploited’);</SCRIPT> into a textbox on a form. If this textbox input is used as direct output to the web browser, it could produce a message box displayed to the user saying ‘exploited’. This is just a basic example of XSS.
ValidateRequest is here to save the day, or is it? In this post, I will take a deeper look at how ValidateRequest works and how it doesn’t work. My purpose is to give other developers a deeper understanding of how security works in .Net so they can write more secure applications.
In the 1.1 Framework, many developers would turn off the ValidateRequest page attribute because it was too restrictive. Getting constantly bombarded with an error message every time we sent a request was unavoidable. The below list shows the list of items that trigger the Validation error in the 1.1 Framework.
1.1 Framework Validation:
- &#
- <alpha, <!, </
- script
- On handlers like onmouseenter, etc…
- expression(
- Looks for these starting characters (‘<’, ‘&’, ‘o’, ‘O’, ‘s’, ‘S’, ‘e’, ‘E’)
This is obviously a pretty strict list of items that would trigger a validation error. In the 2.0 Framework, Microsoft decided to loosen the restrictions on this quite a bit. Below is the list of validation checks in the 2.0 Framework.
2.0 Framework Validation:
- &#
- <alpha, <!, </, <?
- Looks for these starting characters (‘<‘, ‘&’)
As you can see, the validation checks have greatly decreased. The 2.0 Framework validation has carried over into the 3.0 and 3.5 Frameworks as well.
These differences are very important to understand. Not only should we understand what criteria the validators are looking for, but also where that opens security holes. If we are working with a 1.1 Framework application, it is very possible that the developers have turned the ValidateRequest off. This forces the developer to do all the work. When working with the 2.0+ Framework applications, there is a higher probability that the developers have left ValidateRequest on. This allows the framework to do some of the work. The important point here is that ValidateRequest on in 2.0+ will NOT prevent all Cross Site Scripting attacks.
Looking at the two lists above, we can see that malicious users could enter expressions or events into parameters and, under the right circumstances, get those events to fire in the client. This post is already quite long, so I will show how this can be done in another post. It is important to realize that ValidateRequest does not completely protect against XSS. There are other factors that must be considered. Microsoft has the Anti-Cross Site Scripting Library that might be a good idea to implement as well to help protect your application. I will take a look at this library as well.
Comments
2 Comments on ValidateRequest Property (XSS)
-
Seth sencary on
Wed, 21st Oct 2009 1:05 pm
-
James Jardine on
Tue, 8th Dec 2009 8:28 pm
This article triggered my curiosity and I am now looking for what you can put past the validation….
can you please let me know ? I am trying to make the point to my employer that ValidateRequest should not be the only layer of security…
Seth,
Some of the more obvious items that can go past the validateRequest are related to events. Items such as onClick or OnMouseover are possible if the output is written as attributes to an element. It is possible to escape out of the attribute and start your own. There is an example of this in my post about IE8 Cross Site Scripting Filter.
Follow Us
