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
<instead of<and quotes become"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.
- This is the one security area developers fail most often when interviewing for a position at Crowd Favorite. [back]
Popularity: 11% [?]
Joe Casabona adds this Comment:
Thanks Alex- Great post! I’ve been careful about things like SQL injections. Now I know to look for these kinds of attacks too.
August 12th, 2008 at 8:26 pm
ddos help adds this Comment:
The thing that makes XSS attacks nastier than, for example, injections is that creating an XSS vulnerability in your web application is much easier than MySql injection for example. I have personally had to combat XSS vulnerabilities and sometimes they can also be pretty hard to find.
August 13th, 2008 at 10:29 am
Stefan adds this Comment:
And again I’ve learned a lot about XSS!
Thanks Alex!
August 15th, 2008 at 2:36 am
David O'Shea adds this Comment:
“Strip out tags/content you don’t want to support”: I have seen the advice, which I agree with, that you should instead strip out ALL tags/content except that which you DO want to support. If you just strip out things that are “bad”, you might forget something or possibly not know about some special tag which can be used for an exploit on some particular browser. Only letting through the things which you know for sure are okay is safer and more “future proof”.
September 4th, 2008 at 6:16 pm