In depth defense

The security of an application should, as far as possible, avoid having a single point of failure. And yet, in the course of our testing we come across a large number of applications that rely on a single function to protect themselves. We've seen this in web applications which rely solely on ValidateRequest to prevent XSS. While it is secure today, any vulnerability found later, will also render one's application is vulnerable. An application should always try and be self-reliant in protecting itself. In the case of XSS, this means that it should validate all the input itself rather than relying on Microsoft’s filter. It should also encode all the output, just before display so any data that has made it through the crevices still does not lead to a security breach.

We've seen a similar pattern in software protection schemes. A complex algorithm with a challenge and response is used and called in a single function which returns a single true or false value at the start. This can easily be reverse engineered and the call commented out which renders the entire algorithm extraneous.

The point is that the security of an application should be considered at many different levels so that a single break does not render the security scheme worthless. It is much more effective when built into the product life cycle from the start, rather than being added as an afterthought.

Vulnerability in ASP.NET ValidateRequest

The folks at ProCheckUp have found another vulnerability in the ValidateRequest functionality. This is the input filtering that is used by Microsoft in .NET to try and prevent XSS attacks. The attack relies on a number of browser specific ricks such as comments to bypass the filtering. This is not the first time vulnerability has been found in ValidateRequest and we're sure it won't be the last. And still some people persist in using it as their sole line of defense against XSS attacks, even against Microsoft's own recommendations.

The entire paper can be found here.