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 instead of abstract concepts, with a human face on them so they're a little easier for people to understand. For example, SQL injection is kind of like James Bond: He sneaks into places 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 just the client-side script code of the vulnerable page, but the HTML as well. He can use this ability 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 his information is being stolen nonetheless.
- Web Worms Some persistent XSS vulnerabilities can allow attackers to create Web worms. Web worms are XSS attacks that not only affect 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, consuming more and more resources until the server grinds to a halt and crashes.
At this point you should be thinking about XSS less like Rodney Dangerfield and more like Don Corleone: a powerful and dangerous person who deserves your respect! So, how can you find XSS vulnerabilities in your code and, more importantly, how can you fix them? The underlying programming error that leads to XSS vulnerabilities is displaying user input without first correctly validating and encoding that input. If you ever echo users' input back