Cross-Site Scripting: An Old Problem Returns

Today's Best Tech Deals

Picked by PCWorld's Editors

Top Deals On Great Products

Picked by Techconnect's Editors

Illustration by Mark Todd
In May, Web security consultant George Deglin discovered a cross-site scripting (XSS) exploit that involved Facebook's controversial Instant Personalization feature. The exploit ran on Yelp, one of the three sites that Facebook had selected to test Instant Personalization. Deglin was able to obtain not only Facebook profile information shared with Yelp but also the e-mail addresses for that profile's Facebook friends--a potential gold mine for marketers and spammers alike.

Shortly after Deglin's XSS flaw was fixed, another one surfaced on Yelp, and Facebook temporarily suspended the Instant Personalization program on that site.

XSS-based attacks are not new, but the rise of social media adds a new wrinkle to these sorts of vulnerabilities.

An XSS Primer

The most common XSS attack method uses e-mail: A criminal appends special characters, such as those of a foreign language, to an ordinary URL. These characters might tell a Web server to run a script that the crook has crafted. For example, say an attacker appends such a script to your bank's URL and e-mails it to you. If you click the link, believing that it's legitimate e-mail from your bank, your browser sends the script to the Web server, which runs the malicious code and passes a browser cookie with your bank login details to the attacker, who can then log in to your online banking account.

Another type of XSS attack stores the malicious code on a Web server. The attacker logs in to an e-commerce site, for instance, and posts a message containing a script. Some days later, you log in to the site and read the tainted post. As before, the script steals the cookie with your login information and passes it to the bad guy, who can then impersonate you.

A third type of XSS attack hits the Web browser itself. In this scenario, the attacker places a poisoned Flash file on a site that you visit. When your browser downloads the video, the file triggers a script in the browser, and the attacker can then control elements of the page inside your browser.

Web 2.0 and XSS

Today's Websites do a much better job of filtering out common XSS attacks than sites did in the past, but what happens when two sites with very different content-filtering needs decide to partner?

Say you click an ad on site A. Unbeknownst to you, that ad contains an XSS attack that silently directs your browser to site B, a travel site that has full access to your social networking profile. With an XSS attack, to become a victim you wouldn't have to visit site B, log in to it, click anything there, or even know that it exists. Because site B already has access to your social networking profile (and perhaps information on your friends), the criminals behind the ad on site A now have access to that information as well. That's what is starting to happen with Web 2.0 mashups similar to the Facebook-Yelp collaboration.

Protect Yourself

Unfortunately, sites can't prevent XSS attacks simply by encrypting connections. SSL (Secure Sockets Layer), indicated by the little padlock that appears in the toolbar when you browse to an encrypted site, merely encrypts the attack. Generally, site designers have to lock down their sites to prevent XSS exploits.

Users have two ways to avoid XSS attacks, however. One is to ignore links from one site to another: If site A links to, say,, instead of clicking that link you would go directly to in another tab and find the page using the site's search feature. This technique is effective against XSS attacks embedded in the linked URL, but it's inconvenient--and it doesn't help when two sites share content. The other method is to disable scripting languages such as JavaScript within your browser. Even though this can disable desirable features on some sites, you may find it tolerable.

Blocking Dangerous Scripts

Internet Explorer 8 was the first browser to have script-blocking XSS protection built in; Google Chrome soon followed. Both check to see if a script from a Web server is malicious--if it is, they block it. In April, at Black Hat Europe 2010, researchers David Lindsay and Eduardo Vela Nava demonstrated ways to neutralize this approach, but by that time Google had already fixed the problem in Chrome. Microsoft had corrected most of the issues in January (with patch MS10-002) and March (MS10-018), and planned to fix a third flaw in June, so the issue may be fully resolved by the time you read this.

Firefox users can employ the free NoScript add-on to selectively block scripts. For instance, you can unblock a Flash video while blocking other script components on the site. IE and Chrome aren't nearly as granular in blocking suspect scripts--it's all or nothing with them.

One problem with NoScript is that most users don't like the inconvenience of individually unblocking scripts. But blocking and unblocking typically become second nature. You can also authorize all scripts on a given site for a single visit or all future visits, something you can do in IE 8 and Chrome, too.

Note: When you purchase something after clicking links in our articles, we may earn a small commission. Read our affiliate link policy for more details.
Shop Tech Products at Amazon