Debugging an XSS attack

Today I ran across a Cross Site Scripting (XSS) attack in the wild. Since the victimized site is run by a friend, I did a little digging to see how the attack was done so I could tell him about the issue and how to fix it. Here is a little background on XSS attacks and how to debug them and avoid them.1

An XSS attack is when someone is able to inject code into a page – generally when a user can get JavaScript code to execute within a web page. These can do bad things like steal your cookies and do bad things on your behalf, or annoying things like pop up windows and redirect you places.

If you are trying to debug an XSS attack, the first rule of thumb is not to use your main browser. Don’t use anything that has “your” data in it – things like login cookies, etc. Instead, use your secondary browser or your development profile for your main browser if you have one.

Your browser can show you the behavior that the attack is performing, which is useful. However, depending on the attack, getting the HTML source from your browser may not be so easy. Also, many browsers will “clean up” the HTML a bit as they render it, so the HTML you see from your View Source command isn’t always exactly what the web server sent down.

You should use a command line utility like cURL or wget to download the raw HTML source and look through there for the vulnerability.

You’ll probably find a place in the HTML where a tag was closed before you expected it, and a SCRIPT tag somewhere you didn’t expect it.

There are a number of ways to avoid XSS attacks. The main approaches are:

  • Strip out tags/content you don’t want to support. These should definitely include script tags, and also attributes on other tags that can execute JavaScript – attributes like onload, onclick, etc.
  • Encode your HTML output so that angle backets become &lt; instead of < and quotes become &quot; instead of ". This prevents the JavaScript from being executed in the browser because the attempted HTML tags don’t end up as HTML tags, they instead show what would normally be seen as HTML source.

There’s a ton of info on preventing XSS attacks out there on the web. If you’re a web developer, make sure to do a little reading on this.

  1. This is the one security area developers fail most often when interviewing for a position at Crowd Favorite. [back]