The Mike Rothman Security Report

***Editor's Note: If you're interested in the secure B2B identity architecture of tomorrow , make sure you sign up for the Federation and User Centric Identity webinar today!

This month I want to dig a bit deeper into the cross-site scripting (XSS) attack. The type of issue is rather pervasive out there in the wild, and most web site developers have no idea what an XSS is and how to fix it - until their users are getting hurt. The sad truth is that many web sites do''t pay as much attention to XSS attacks because they aren't used to compromise the web site's data.

These attacks are used to steal information from the browser of the user, making them perform unauthorized scripts because they believe the website they are visiting is trusted. It's a nasty attack and relatively easy to detect, though harder to stop. Let's jump in.

What is XSS? How does it work?

A cross-site scripting attack uses an unsuspecting web site to launch an attack against a visitor, leveraging the "trusted" nature of the underlying web site. When the visitor's browser renders the compromised page, the malicious script, which is stored on another site (ergo CROSS-SITE), is executed providing access to information resident in the browser of the visitor.

XSS comes in two flavors. The first, called a "stored" attack, involves the offending script command to be entered into a text block. This could be a comment field, search box or message forum, etc. This can be a problem for any of the "Web 2.0" types of applications that allow user comment and feedback. If it allows visitors to insert and store data in your application, then it's vulnerable to a stored XSS attack.

The other type, "reflected XSS" involves more traditional social engineering. The visitor needs to click on a link, which has the malicious script embedded. The web site then "reflects" the script back to the visitor and it's executed in the visitor's browser.

What is the impact of a successful XSS attack? Who gets hurt?

Basically, the user gets hurt, not necessarily the web site, and that's been the big sticking point in taking XSS attacks seriously. The first generation of XSS attacks really focused on nuisances like cookie stealing, but more recently a new type of very malicious XSS is appearing. These new attacks can bring down web sites, cause users to take actions like they don't want to (like the Samy MySpace worm), and even host a phishing site within a real site.

To illuminate a bit on this last example, imagine that you are buying something on yourfavoritestore.com. So you go to their web site and everything checks out. The SSL certificate is right and the domain is right. You're good, right? Wrong. What happens if you enter in your userID and password and it turns out a malicious script in a comment field on that page launches a script that takes the data from your form and sends it to Eastern Europe? You'll never even know what hit you.

It's like an ATM attack where the bad guys bolt a fake front on an ATM machine. The fake front reads your card and then passes it to the real ATM machine. You get you money, like you expect - but the bad guys have your number and your PIN. XSS can do that, but a lot more transparently and with a lot less risk to the attackers. No wonder this attack is very prevalent.

Detecting the XSS

So how to you detect a potential XSS problem? Technically it's not that hard, although the scale of the problem is significant. Basically you have to check every form and field in all of your web sites. Anywhere someone can enter text into your web site needs to be checked. Obviously that's a tall order for a human, so you are best off looking at scanners to help automate the process.

How to fix the XSS?

Fixing the XSS is also readily doable. Here are three options to consider:

1. Web application firewall - Yes, a WAF will help to block if your web site calls out to a foreign site to execute a script. So if you front end your application with a firewall, you can largely eliminate the problem. Of course, all your traffic needs to go through that firewall so make sure there aren't alternate routes into the application that could get around the defense.

2. Code frameworks - A number of the packaged application frameworks are down with XSS, and have built-in validation processes to make sure that forms and fields cannot accept foreign scripts. Microsoft (once again) is leading the business on this issue, with ASP.net offering many of these advanced validation checks built-in. J2EE and Rails offer a lot of tips and documentation to defend against XSS attacks as well.

3. Developer training - It's great that a lot of the frameworks add defenses to stop XSS, but ultimately you want your developers to be aware of the attack vector and to code their applications with these issues in mind. Of course, we are a ways off from developers caring about security, but through consistent evangelizing and persistent testing of applications, you can get the developers on board.

XSS is a scourge, but a manageable issue. With a little preventative scanning and some proactive mitigations, much of the risk of XSS can be eliminated from your web sites.