Show Some Respect to Cross-Site Scripting


James Bond, Mr. Creosote, and Don Corleone are just some of the personas Bryan Sullivan uses for security vulnerabilities. In this week's column, Bryan pays homage to the one vulnerability that gets the least respect, cross-site scripting (XSS), and calls it the Rodney Dangerfield of vulnerabilities. The problem is that XSS vulnerabilities are nothing to laugh at, and, as Bryan explains, you should start showing this vulnerability some respect before you get slapped by an XSS threat.

Sometimes I like to describe security vulnerabilities as if they were people or characters, rather than abstract concepts.  With a human face applied to them it’s a little easier for people to understand my explanation. For example, SQL injection is kind of like James Bond: He sneaks into places that he's not supposed to have access to and then escapes with all of your secrets. A buffer overflow is like Mr. Creosote from Monty Python's The Meaning of Life: He tries to cram way too much data into a space that's not meant to hold it and the results are disastrous. If Cross-Site Scripting (XSS) were a person, it would definitely be Rodney Dangerfield. XSS never gets any respect! Many people still think of XSS as just a silly vulnerability that can only be used to pop up message boxes in the victim's browser. Recently, a representative from McAfee stated that the presence of XSS on Web sites would not prevent those sites from qualifying for McAfee's "Hacker Safe" certification. I strongly disagree with this position. Just look at some of the ways XSS can be exploited:

·        Session hijacking: This is a classic example of exploiting an XSS vulnerability. The attacker injects script into the vulnerable page so that visitors to that page will automatically, and silently, send their document cookies to the attacker. Depending on the site attacked, those cookies may include the user's session and authentication tokens. Once the attacker gets these tokens, he can impersonate the user on the vulnerable site, essentially committing a form of identity theft. A vulnerable email application might allow an attacker to read the victim's mail or to send new mail in the victim's name. A vulnerable banking application might allow an attacker to empty the victim's checking account into his own.

·        Phishing:  In a successful XSS exploit, the attacker can often alter not only the client-side script code of the vulnerable page, but the HTML, as well. This ability can be used to add new form fields of his choosing, perhaps two text-box inputs labeled "username" and "password" along with a "submit" button. Of course, the attacker will make sure that this data won't get submitted back to the legitimate Web site, but rather back to him at his evil Web site where he can use it at his leisure. This is the ultimate phishing attack since the victim really is at the legitimate Web site; it's not the typical hoax site setup, but information is being stolen, nonetheless.

·        Web worms:  Some persistent XSS vulnerabilities can allow attackers to create Web worms. Web worms are XSS attacks that affect not only the target user, but also spread out to affect that user's friends or contacts and, from there, to those peoples' friends or contacts, and so on. Popular targets of this kind of attack are Web-based email clients (the worm spreads through the target's contact list) and social networking sites (the worm spreads through the target's friend list or alternatively spreads to anyone who views the target's profile). Web worms can grow at an exponential rate and consume more and more resources until the server grinds to a halt and crashes.

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.