Cross site scripting: an old-new threat
Cross-site scripting is unusual among web vulnerabilities in that it targets the client instead of the web application itself.
According to NIST’s NVD, cross site scripting or XSS is the single most common vulnerability. It makes up ~12% of all vulnerabilities since 2008 by itself – total, not just in web applications! – and the ratio is increasing.
Cross site scripting has had a spot on the OWASP Top Ten since its inception, though it is not as stable as Injection. Starting off at #4 in 2003-2004, it catapulted to #1 in 2007, #2 in 2010, #3 in 2013, and finally #7 in 2017. Due to its high incidence rate, it is all but guaranteed to stay on the Top Ten, but there are some factors in its significant drop that are worth investigating.
2*2 is sometimes 3, but it’s really just 2
First, let’s take a look at what the various types of cross site scripting are and how they work.
The commonly used classification of cross site scripting (from 2005, as per Amit Klein from WASC) differentiates between three subtypes depending on the source and destination (sink) of the attack string:
- Persistent (Type I): The web server stores user input (typically in a database). On a later request, it reads the stored data and inserts it into the page as HTML.
- Reflected (Type II): The web server parses user input from the request. It then immediately returns it – ‘reflected’ – verbatim to the user in the response as HTML.
- Server XSS: The server includes untrusted data (received directly or taken from a persistent storage) in the HTML.
The main distinction between the server/client is where the malicious user input interacts with the logic used to generate or render the page, and what the developer can use to prevent the cross site scripting vulnerability.
The more cross site scripting changes, the more it stays the same
Cross site scripting exploitation has undergone a lot of evolution since the early 1990s, with new techniques in the context of AJAX, HTML5 functionality, and even CSS3. On the other hand, the core cause of the vulnerability and its prevention has basically not changed.
Which brings us to the good news: the increased popularity of auto-escaping frameworks such as Angular / React / Razor / Jinja2 is directly responsible for cross site scripting being a much lower-risk vulnerability today than it was in 2004, which also explains why it only got 7th place in the OWASP Top Ten 2017. It is still possible to use user input in a vulnerable manner in those frameworks, but at least it takes deliberate effort now!
Dealing with cross site scripting is not too difficult, but the first hurdle is the biggest one: awareness. Check out our Web application security course: it covers all the subtypes of cross site scripting – as well as the various platform-independent protection measures – in depth. Or, if you want a focus on a certain programming language for anti-XSS solutions, take a look at our other web application security courses for Java, C#, or Python; each of them covers XSS in depth.