A sense of history

Cross-site scripting (XSS) vulnerabilities provide some of the most interesting and creative exploits. These exploits range from banal pop-up windows that annoy people to using the browser as a port scanner to insidious theft of authentication credentials. The fundamental cause of the vulnerability is well known and has been described in many other places. What isn't commonly discussed is the history of XSS (more generally described as HTML injection) and the provenance of the security concern.

The original CERT advisory was published on February 2, 2000.

Keep in mind that the term "XSS" is neither an accurate description of the vulnerability or the original short-hand reference for attacks that modify the HTML DOM or execute scripting code in the browser. USENET references to "malicious html" and "malicious javascript" go back as far as 1996. In March of that year a post showed up on comp.security.unix that described what malicious content might do:

A funny-looking link can persuade a fancy browser to send mail, perhaps to exploit a bug in the mail program to do something much worse. The newest craze, Java, actually downloads programs into the browser, and runs them.

Another post in comp.sys.acorn.misc in June of 1996 contained a nice description of the potential of malicious JavaScript:

Another 'application' of JavaScript is to poke holes in Netscape's security. To *anyone* using old versions of Netscape before 2.01 (including the beta versions) you can be at risk to malicious Javascript pages which can
a) nick your history
b) nick your email address
c) download malicious files into your cache *and* run them (although you need to be coerced into pressing the button)
d) examine your filetree.

Now, compare the previous description with the definition of XSS from the most recent OWASP Top Ten list.

Cross-site scripting, better known as XSS, is in fact a subset of HTML injection. XSS is the most prevalent and pernicious web application security issue. XSS flaws occur whenever an application takes data that originated from a user and sends it to a web browser without first validating or encoding that content.

XSS allows attackers to execute scripts in the victim’s browser, which can hijack user sessions, deface web sites, insert hostile content, conduct phishing attacks, and take over the user’s browser using scripting malware. The malicious script is usually JavaScript, but any scripting language supported by the victim’s browser is a potential target for this attack.

Of course, it's important to have a term or phrase that codifies a type of web application vulnerability. XSS serves this purpose quite well -- think of it as the Kleenex or Xerox of HTML injection vulnerabilities. On the other hand, there's clearly a fundamental problem with web application development and web browser design if such a long-standing vulnerability can continue to pose such a threat to web security.