Software Testing & QA Online Community > Detail: Show Some Respect to Cross-Site Scripting
|A StickyMinds.com Original|
Show Some Respect to Cross-Site Scripting
By Bryan Sullivan
Summary: 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:
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 to them (for example: "Your search for 'foo' returned 1337 results") or store users' input and display it to other users (for example, if your site includes a wiki or a message board), then that code may be vulnerable to XSS. Search out conditions like this in your source code. Then ensure that this functionality is secure against XSS by encoding it with the appropriate encoding algorithm. For example, if the user input will be rendered in the page as HTML, then perform HTML encoding on the input text before that text is echoed in the response. This will cause malicious input text like "" to be encoded as "", which will render in the browser as the text "" and not be interpreted as a script command. Similarly, if the user input will be rendered in the page as a URL (for example, as the href attribute of an element) then you should apply URL encoding (and then subsequently HTML encoding) on the input text. A complete list of possible output formats and corresponding encoding types is beyond the scope of this article, as are methods for dealing with situations where you might want to allow the user to input HTML or script. However, there are some excellent additional resources available that detail these solutions. (See resources listed below.)
- 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.
About the Author
Bryan Sullivan is a security program manager on the Security Development Lifecycle (SDL) team at Microsoft. He is a frequent speaker at industry events, including Black Hat, BlueHat, and RSA Conference. Bryan is also a published author on Web application security topics. His first book, Ajax Security was published by Addison-Wesley in 2007.
Back to Top
StickyMinds.com Weekly Column From 6/9/2008