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).
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):
... 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:
- .Net Cross Site Scripting – Request Validation Bypassing, By the Website Vulnerability Numbers: .Net XSS Request Validation Bypass and XSS with a little help from ASP.NET and IE9 (for the ...<%tag... exploit)
- here is a not-for-production fix: Another Request Validation Bypass?
- Bypassing asp .Net “Validate Request” for stored XSS (didn't seem to work anymore)
- Security Advisory 07-001 – ASP.NET Request Validation Bypass (fixed)
- Incorrect Handling of XSS Protection in ASP.Net (fixed)
- Bypassing ASP .NET “ValidateRequest” for Script Injection Attacks (from 2008, fixed meanwhile)
The first batch of links is the one that still works today (and was marked with not-fix by Microsoft).
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
Note that this only worked in IE 9,8 and lower (shown above), since IE 10 is ok (shown below):
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.
