How Cross Site Scripting was discovered

Hi, Michael Barrett here.

These days, most of us have to grapple with preventing Cross Site Scripting and other web-based attacks from occurring against our web sites.  What's lost in the mists of time is who discovered it and why. 

I had the unique privilege of being there when a couple of really talented security testers (Marvin Simkin and Toby Barrick) came up with what we now know as Cross Site Scripting.  Of course, it's entirely possible that another individual or team discovered the same idea at roughly the same time - history is littered with such examples - so the re-telling of this story shouldn't be taken as invalidating any other suggestions of how it was first discovered.  I should add that I've never met anyone who claimed to have found it before Marvin and Toby did, and I think there's a very good chance that they really were the first ones to think of this.

Recently, Marvin wrote up how it all happened - when we all worked at American Express in the late '90s - and so here's his telling of how it happened:

"I think of it more as "discovering" than "inventing" because I didn't set out to make a new attack vector -- I just stumbled across it.

 Toby, an associate of mine, and I were testing a new web site in development which allowed you to customize a few pages with links to your favorite services etc. We noticed that the customizations were associated with a cookie that basically told the site who you are. The contents of the cookie was your email address.

We argued that the cookie value should be something harder to guess. If I know your email address I could tamper with my cookie and see your custom page. The developers, as they often do, said "So what? So you see my links. There's no harm. We're not going to fix it."

Toby pointed out that part of the customization was a name field so the page could say "Welcome back Mark". Toby said you could change someone else's name to something foul or insulting. Developers didn't budge. Toby then figured out some obscure encoded character in some weird font that would display a skull and crossbones. He also embedded it in a FONT COLOR=RED tag. Still not scary enough. So the question came back to us "what's the worst thing you can do" given the ability to maliciously control the content of a page someone else will view?

Well, that is exactly the wrong question to ask me. Because it set me thinking of possible attacks. What's the most harmful HTML tag? Played with that a little... hey, not just HTML, what about SCRIPT? Not merely formatting but now I have control of your browser! Still didn't think about stealing your cookie because in this attack I already had your cookie to start with (and didn't realize it would give me your OTHER cookies).

Now putting crazy HTML and/or scripts into persistent stores like bulletin boards (called blogs today) was already a known attack, and many people were filtering any user submitted page content. I don't claim to be the first on persistent XSS. But if I'd thought of it, I could have done something like that here.

This exercise however provided the mental positioning for when I was testing another site and found I could inject page content through something in the URL. Again the developer response was "So what? You're only ruining your own page. Why would you attack yourself?"

It occurred to me that if I could entice someone else to view my crafted URL (this was before phishing took off big time) I could immediately run my code in their browser. This was, I suspect, the first use of "reflected XSS". I knew right away that would give me access to their Document Object Model. What's the most valuable thing in the DOM, to read or alter? If I can attack a session cookie it would provide access to financial stuff. OK, now how to I get your cookie back to me, the attacker? It didn't take long to realize an embedded image tag with an HREF to my server would do the trick, and I demo'd stealing cookies in real time first to my boss, then step by step up the management chain until we got to some higher execs I didn't even know.

I found XSS holes in the default "404" error page of the three top web servers at the time. Together they served 95% of the sites on the net. Hypothetically speaking, at that moment, I pwned them all! :)

I don't know the exact date of discovery because (1) it happened gradually, over several weeks, with back and forth debates asking me to prove the issue by strengthening the attack and increasing the potential harm, and (2) I didn't know it was going to be a big deal so I had no reason to take note of it at the time. But I have some emails discussing it in September 1999, so it was at least then if not sooner, and I have a code snippet dated November 3, 1999 from a spider I modified to scan for XSS. I think it is very likely this was the world's first reflected-XSS scanner.

A few of us got on the phone to the MS security center and told them about it. They hadn't heard of it before and had no solution. A few months later they made the issue public through the CERT. I was not able to disclose it myself and claim credit because of nondisclosure agreements in effect at the time. So since then many companies and many products have risen from my discovery, but I have yet to see much in the way of royalties. Oh well. :)

Oh -- and I didn't name it "Cross Site Scripting". I called it JavaScript injection. I suppose I was thinking too small by limiting it to JavaScript, but that seems to be the primary attack vector even today. It has remained #1 on several top-ten lists for over a decade now, and I don't see it being solved any time soon -- for the same reasons as it originally arose. Developers under too tight deadlines to spend time validating inputs. Or, simply, being unaware of negative use cases and designing / testing only to positive use cases."

Comments

[David Ross]

I was also doing research in this space on the Internet Explorer team in late 1999. (Related blog: http://bit.ly/cmc2jo) It's certainly quite common in real life for ideas to be conceptualized by different individuals independently. But I really am surprised by your 2nd to last paragraph. Georgi Guninski's browser bugs were an inspiration on the work I was doing, that is something I recall. But beyond that I'm sort of left scratching my head.

[David Ross]

Ahh, less head-scratching now. I found a reference to an issue on IIS error pages from that timeframe that I think is a match.

[Marvin Simkin]

David, the blog you reference says "The research leading up to the disclosure dates to mid-December 1999". I had a working XSS scanner in early November 1999. so I think it is fair to assume I'd been developing it a while before that, though I don't recall the exact date when I started.

I agree it is likely several people were moving in the same direction at the same time. Again I don't recall exact dates, but is it possible our conference call with the Internet Explorer security team (in October? November?) was part of the inspiration for the research push in December?

[Marvin Simkin]

Regarding Georgi Guninski's browser bugs (a researcher I highly respect, by the way) I'd comment that XSS was not a browser bug, but rather an unexpected outcome of several parts all working as designed -- including, for example, 404 error pages which would echo your Referer header without sanitizing it. The only bug was trusting user input -- but "Who would attack themselves?" was the thinking at the time.