Cross-site scripting (XSS) is a security concern that has persisted for over two decades in the world of application security. For newcomers to this field, XSS is often one of the first vulnerabilities they encounter due to its prevalence in web applications and it’s relatively straightforward nature. In this article, we delve into the origins of the term “cross-site scripting,” explore the various types of XSS vulnerabilities and their evolution, and contemplate whether simplifying the terminology could enhance our understanding of this issue.
As Jeremiah Grossman explains below, the original acronym for the term was actually “CSS”, but this was slowly phased out as we already had Cascading Style Sheets in the web development world:
What has changed over the years are the different types of XSS. We started off with reflected XSS. This is when a malicious script comes from an HTTP request:
We’ve now established the following:
- “cross-site” only applies to one current type of XSS (reflected/non-persistent)
- “scripting” is vague and no longer relevant, as most modern browsers do not support other scripting languages such as Flash, VBScript etc
With these points, it’s worth considering if we need all of the different types. In fact, in 2012, OWASP had considered the proposal to change the types to Client XSS and Server XSS, while maintaining that there could be reflected and stored variants of each of these. These proposed types don’t seem to have taken off, and most in the security community still use the old types. Considering that, we must think about why that might be. It could be argued that these new types don’t really solve the underlying problem, that there is overlap, and we might be overcomplicating the definition of the vulnerability.
The cons of this simplification are that:
- We don’t classify whether the vulnerability is server-side or client-side.
- There is no indicator of the vulnerability being persistent or non-persistent.
Whether the vulnerability is server-side or client-side, the top controls that most would normally recommend as part of a defense-in-depth approach to mitigate this vulnerability are largely the same:
- Validate input server-side to ensure that it is of the expected format, length, type and range.
- Encode output to ensure that input including special characters is displayed, but not executed as code in the browser.
- Implement a Content Security Policy (CSP).
The first two controls have been around for a long time and are considered to be the first you should implement by web application security authorities such as PortSwigger. The third is a newer control but makes it very difficult to pull off an XSS attack when configured properly. With this in mind, does it matter whether the vulnerability is server-side or client-side? Food for thought, and we’d love to hear more about your opinions on the matter.