.Net has a feature called request validation which detects malicious inputs and blocks the request.

By its nature, request validation is not a precise science. OWASP clearly recommend to only rely on request validation as defence-in-depth, not as a security boundary.

I am updating a .net security training course, and I like to include an example of why you should not rely on request validation. Sure, I could tell the trainees "don't do it" - but an example is very powerful.

I have found that request validation in .Net 4.5 has been tightened, and my previous methods of bypassing it no longer work. Are there any publicly known ways to bypass .Net 4.5 request validation, for XSS? The most recent link I found was this.

  • shurely <input would trip input validation (IIRC it's <[A-Za-z0-9] which trips it... ) Jan 26, 2015 at 17:41
  • 2
    yes but don't call them shurely.
    – RoraΖ
    Jan 26, 2015 at 17:46
  • 2
    To help make this a better question, can you edit the question to tell us what you've tried, what research you've done, and anything you know about how request validation works? There's lots of prior work on bypassing XSS filters (see, e.g., adambarth.com/papers/2010/bates-barth-jackson.pdf); have you read them to see if any of them contain anything useful?
    – D.W.
    Jan 26, 2015 at 19:06
  • @D.W. - I have edited to make it clearer. Thanks for the link, I had not seen that one.
    – paj28
    Jan 26, 2015 at 20:34

3 Answers 3


There area a number of places that Request validation may be bypassed, depending on the architecture and function of the application under review, which is likely why Microsoft don't recommend relying on it.

  • Data which enters the application via another channel (e.g. an API) will not be affected by request validation and so could cause XSS issues if that data is rendered without any additional controls.
  • Request validation only really helps where data is placed into an HTML context, where it's placed into a JavaScript context for example it won't provide good protection.
  • Request validation doesn't cover all data sent from the client. For example if the application processes data from user HTTP headers (e.g. User agent) it can render the site vulnerable to XSS.
  • Data can enter the application via areas such as file upload, which again won't always trigger request validation.

Update Another one that might bypass Request Validation is the use of certain Unicode characters in place of the blocked ones. In some cases MS SQL server will convert these characters into the ASCII equivalent when the data is saved to the database. This can allow for an ASP.Net application to be vulnerable to XSS even with an HTML vector. for example

<script >alert(1)</script>

if saved and returned, could result in xss.


If the page context of the XSS is a tag on an input attribute, e.g.

<input type="text" name="address" value="<xsshere>"/>

Then the following payload works:

" onfocus="alert(1)" autofocus="

I would note that if you are using the default binding providers in ASP.net MVC and you then post JSON to a controller, then the posted JSON will not trigger any request validation, even when 'dangerous' content is present.

This could be demonstrated relatively trivially with a simple ASP.net form that posts in a standard fashion and will trigger the validation.

Taking the same data and posting it to the same action as JSON via fiddler (for example) would not result in the same validation.

Sample noted here:


And also commented on in OWASP site on request validation:


There are known, documented bypasses (such as JSON requests) that will not be addressed in future releases, and the request validation feature is no longer provided in ASP.NET vNext.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .