Sunday 1 June 2014

Bypassing asp.net request validation detection, but it is a vulnerability?

Defence in Depth is a good strategy, specially since part of its core principles is the idea that some of the security measures applied will fail. The problem with NOT doing defensive-in-depth coding, is that if there is a way to bypass the security control, then the app can be exploited.

Asp.NET Request Validation is one of those security measures that can sometimes backfire, since it can be used instead of output encoding (in context) the data shown to users (i.e. there is a false sense of security provided by the use of that 'outside-of-the-application security filter').

But since fixing vulnerabilities has a real cost, one must be able to make the business case for the fix (i.e. show that there is a significant risk for the target application).

For example, do you think that following scenario is a 'real-vulnerability' (which should be fixed?):
  • Asp.net website has Request Validation Enabled
  • There is a page with a reflected XSS (quasi)vulnerability
  • There is a bypass for the Request Validation that only works in IE
  • On the scenario where Request Validation can be bypassed (in IE) the same IE version is able to detect it via its current Anti-XSS detection (and disable the payload)
This is one of those cases where although there a 'vulnerable' page, the number of affected users is very small, so the interesting question is: is there a business case to fix the vulnerability?

I think a more interesting (and relevant) question is: Is this an one-off vuln, or, are there other XSS vulnerabilities in that website, specially persistent XSS vulns?

XSS vulns tend to be caused by specific coding patterns, and usually when there is one, there is a high probability that more will exists. Which is why it makes more business sense to make sure (first) that the real scale of the problem is identified (ideally in a programatically/SAST driven way).

Here is an example of this in action.

I was doing a search on the JBI website (for whom I'm delivering a course on Java security later this month):


... and noticed that the search functionality:


... would show the typical .NET Request validation error on http://www.jbinternational.co.uk/CoursesList.aspx?search=AAAA<H1>Ebbb


... which is protecting the 'Search results' from reflected XSS (note how the 'search' value from  http://www.jbinternational.co.uk/CoursesList.aspx?search=AAAA<+H1+>+'+"+bbb is replayed with no encoding):


At this stage we now that this page is vulnerable to reflected XSS if: 
  
   a) we can put a payload that bypasses .NET Request Validation
   b) the browser running the exploit does not detect the script.

I couldn't remember the latest/greatest way to bypass the .NET Request Validation, so a quick google search revealed:

To see that in action, we can use this payload to popup an alert: http://www.jbinternational.co.uk/CoursesList.aspx?search=<%tag onmouseover="alert('xss')">hover here



 .. or change all link's contents with  <h1>xss using:  http://www.jbinternational.co.uk/CoursesList.aspx?search=<%tag onmouseover="($('a').html('<'%2b'h1>xss'))">hover here


Note that this only worked in IE 9,8 and lower (shown above), since  IE 10 is ok (shown below):



... and with the IE built in XSS filter disabled.


In this case, it seems that the risk of exploitation is quite low for reflected XSS, but if there is an persistent XSS vuln, then the .NET's Request Validation will not prevent the injection of payloads.