With XSS, Don’t Bring a Knife to a Gun Fight
One of the primary weapons in a developer’s arsenal for stopping cross-site scripting (XSS) is output escaping. If an attacker can insert special characters into a page (such as < and >), they can potentially add new HTML or JavaScript and wreak havoc. By escaping data rendered by a page, you can change < to < – the latter still gets rendered by the browser as < without creating a new HTML element.
However, it’s important to understand that this defensive strategy must include the concept of contextual escaping. That is, what characters you escape and how you handle them depends on the context of the output.
For instance, simply escaping or filtering every < and > is generally not enough to protect a web application. I’ve seen mainstream sites that escaped these characters, but then left quotation marks unchanged. When a parameter is rendered as HTML, " or ' may seem rather harmless. But consider this bit of code:
<script>var x = "parameter value";</script>
If the parameter value rendered here included a quotation mark, it would complete the variable definition and the rest of the parameter could be executed as JavaScript. I was reminded of contextual escaping’s importance just this week when I read this example of an XSS vulnerability in the password manager LastPass. In this case, the application properly escaped quotation marks in a script context, but still allowed characters that could close the script element and add a new one.
The OWASP XSS Prevention Cheat Sheet includes more details on characters to watch for in several common web app contexts. And remember that XSS in a JSON interface or iframe widget can be just as dangerous as obvious XSS in a search results page. Take note of where your application outputs data and make sure your XSS defenses match each context.