Gmail XSS vulnerability by Peter

Gmail

Slashdot is reporting that a hole in Gmail could potentially allow nasty people to view your entire Gmail contact list remotely. This type of vulnerability is commonly called Cross-Site Scripting or XSS.

All you have to do is have Gmail open, and browse to a website with some malicious JavaScript. The loophole in Google’s code means that this website can siphon off all your contact information.

This attack appears not to be very widespread at the moment, and I have no doubt that Google will be fixing it very quickly – especially now that it’s made the headlines.

This seems a perfect opportunity to explain XSS – some of the ways it can happen and how much of a problem it poses.

XSS is a problem that every web application has to take very very seriously. It exploits JavaScript – a very useful technology, but also very powerful. If you remember, JavaScript powers all the Ajax stuff we’re seeing nowadays and provides a lot of extra functionality beyond just static pages of text and HTML forms.

One of the ways in which this can happen is that a malicious person will place some nasty JavaScript on their target site. Our malicious person can now run pretty much what they want on every visitor’s browser that visits the hijacked page. For example, they could steal people’s session information and save it to their server, which might let them break in to the affected accounts and use them for malicious purposes.

But that’s just one way in which XSS can happen and one possible outcome. The Wikipedia page on XSS has some real-life examples (there’s a bit of jargon to navigate here):

  • Netcraft announced on June 16, 2006 that a security flaw in the PayPal web site is being actively exploited by fraudsters to steal credit card numbers and other personal information belonging to PayPal users. The issue was reported to Netcraft via their own anti-phishing toolbar. Soon after, Paypal reported that a “change in some of the code” on the Paypal website had removed the vulnerability.
  • On October 13, 2005 Samy exploited a security flaw in MySpace resulting in over one million friend requests being made to its creators profile. Qualifying as a type 2 vulnerability, it used multiple XMLHttpRequests to propagate itself.

If you ever wondered why you are blocked from using JavaScript on sites like MySpace, and other sites where you can put HTML – this is why. You would have free reign to do all sorts of things, including XSS. Sure, it might just be a couple of irritating pop-alert boxes

XSS is a real problem – the good news is that if web developers are paranoid and take great care in building their applications safely, these holes are less likely to emerge.

The bad news is that there’s not very much the average user can do to avoid these problems. Aside from blocking JavaScript everywhere, or being selective about where it runs, which is a bit too clunky for most people, you just have to follow standard security practices and be prepared for these things to emerge.

Posted in Explainer,Uncategorized. January 1, 2007

1 Comment

  1. [...] In the meantime, this begs the question – how much customization is too much? At what point do we need to worry about compromising a user’s security? Of course, major sites like MySpace face this problem on a daily basis – in fact we reported on a similar issue at Google a few weeks ago. The web 2.0 space demands customization – however there are obvious drawbacks. It will be occurrences like these that help to define the line between security and creativity. Posted in Web 2.0, Web development, Security. January 14, 2007 0 Comments » [...]

    Pingback by Gizbuzz » Twitter Compromised — January 14, 2007 @ 11:04 pm

Subscribe to comment feed

Sorry, the comment form is closed at this time.