Home » Data Protection » Application Security

Software Vulnerability Disclosure: The Chilling Effect

How the Web makes creating software vulnerabilities easier, disclosing them more difficult and discovering them possibly illegal

The speed with which Web vulnerabilities have risen to dominate the vulnerability discussion is startling. Between 2004 and 2006, buffer overflows dropped from the number-one reported class of vulnerability to number four. Counter to that, Web vulnerabilities shot past buffer overflows to take the top three spots. The number-one reported vulnerability, cross-site scripting (XSS) comprised one in five of all CVE-reported bugs in 2006.

To understand XSS is to understand why, from a technical perspective, it will be so hard to apply responsible disclosure principles to Web vulnerabilities.

Cross-site scripting (which is something of a misnomer) uses vulnerabilities in webpages to insert code, or scripts. The code is injected into the vulnerable site unwittingly by the victim, who usually clicks on a link that has HTML and JavaScript embedded in it. (Another variety, less common and more serious, doesn't require a click). The link might promise a free iPod or simply seem so innocuous, a link to a news story, say, that the user won't deem it dangerous. Once clicked, though, the embedded exploit executes on the targeted website's server. The scripts will usually have a malicious intent—from simply defacing the website to stealing cookies or passwords, or redirecting the user to a fake webpage embedded in a legitimate site, a high-end phishing scheme that affected PayPal last year. A buffer overflow targets an application. But XSS is, as researcher Jeremiah Grossman (founder of WhiteHat Security) puts it, "an attack on the user, not the system." It requires the user to visit the vulnerable site and participate in executing the code.

This is reason number one it's harder to disclose Web vulnerabilities. What exactly is the vulnerability in this XSS scenario? Is it the design of the page? Yes, in part. But often, it's also the social engineering performed on the user and his browser. A hacker who calls himself RSnake and who's regarded in the research community as an expert on XSS goes even further, saying, "[XSS is] a gateway. All it means is I can pull some code in from somewhere." In some sense it is like the door to a house. Is a door a vulnerability? Or is it when it's left unlocked that it becomes a vulnerability? When do you report a door as a weakness—when it's just there, when it's left unlocked, or when someone illegally or unwittingly walks through it? In the same way, it's possible to argue that careless users are as much to blame for XSS as software flaws. For the moment, let's treat XSS, the ability to inject code, as a technical vulnerability.