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, somerandomsite.com/page, instead of clicking that link you would go directly to somerandomsite.com 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.