7

.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... ) – Rоry McCune Jan 26 '15 at 17:41
  • 2
    yes but don't call them shurely. – RoraΖ Jan 26 '15 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 '15 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 '15 at 20:34
10

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.

4

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="
2

I would note that if you are using the default binding providers in ASP.net MVC and your 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 posted data and posting it to the same action as JSON via fiddler (for example) would not result in the same validation.

Sample noted here:

https://weblogs.asp.net/imranbaloch/security-issue-in-asp-net-mvc3-jsonvalueproviderfactory

And also commented on in OWASP site on request validation:

https://www.owasp.org/index.php/ASP.NET_Request_Validation#Extending_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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.