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?
