RedTeam

Cross Site Scripting (XSS) vulnerabilities are still one of the security problems you find in almost every web application. If the application’s interaction surface is reasonably large, it’s really just a matter of time.

For us, this means that in almost all web application pentests, we find XSS vulnerabilities to be documented. And there’s one thing we always tell people when we present our results: If possible, don’t code your own filter, but use a well-tested XSS prevention library.

Now this should be a no-brainer, but surprisingly often you find self-written code in web applications that’s supposed to defend against XSS. And it fails. Because XSS filtering is hard, which people still tend to disbelieve. All you need to do is to check for those angle brackets and single ticks, right? Well, have a look at the much cited XSS cheat sheet if you don’t believe how hard XSS filtering can really be.

Now I don’t want to go into the details of XSS filtering, the OWASP XSS Prevention Cheat Sheet already has a very nice overview of what to pay attention to. Point 1.6 is what we also say though: You need a security encoding library. OWASP is recommending their own ESAPI project, but there are of course also other libraries for different languages (like e.g. HTML Purifier). Today’s web application frameworks oftentimes implement XSS prevention measures, so have a look at your favourite framework and if there’s already some builtin XSS mitigation functionality.

The next thing, and that’s also explained in the cheat sheet, is the differentiation between input validation and output encoding and why you preferably should use both. Many XSS attacks will already be prevented by simply encoding your output properly.

Also, always have an eye open for new developments. HTML5 is around the corner and people are already working on the HTML5 Security Cheat Sheet. Don’t get lazy because you added a filtering library to your code. It might not work against the newest attacks.