ASP.NET ValidateRequest does not mitigate XSS completely

  • Article

As a security guy, I can safely say that there is no magic bullet to mitigate any security problems completely, and cross-site scripting(XSS) bugs are not exceptions.  Since ASP.NET 1.1, ValidateRequest can be configured in web.config to check and reject dangerous inputs, and HttpRequestValidationException is thrown before the input is even processed by your code.  For example, <script> would be caught by ValidateRequest.

During my security reviews, I routinely find that many web applications turn on ValidateRequest (It is on by default), and do not follow XSS mitigation techniques, such as output encoding by HTMLEncode or ACE Anti-XSS library.  They believe that ValidateRequest can fix all XSS problems.

However, there are a couple downsides of relying on ValidateRequest:
1. ValidateRequest may miss some crafty inputs.  Please read MS07-040 for a recent MSRC fix on ValidateRequest.

2. ValidateRequest cannot be turned on in all cases, as characters that trigger XSS may also be needed in valid user scenarios.  For example, AJAX transmits XML blobs between client and server, but ValidateRequest will throw HttpRequestValidationException as it contains "dangerous" characters, such as < and >.  Exchange 2007 OWA cannot run with ValidateRequest turned on. 

In conclusion, ValidateRequest should be turned on if it does not block valid user scenarios.  However, even with ValidateRequest turned on, it MUST not be regarded as a sure-fire way to mitigate XSS.  Please read https://msdn2.microsoft.com/en-us/library/ms998274.aspx for full XSS mitigation.

Comments