GMail Vulnerable To Contact List Hijacking
Anonymous Coward writes "By simply logging in to GMail and visiting a website, a malicious website can steal your contact list, and all their details. The problem occurs because Google stores the contact list data in a Javascript file. So far the attack only works on Firefox, and doesn't appear to work in Opera or Internet explorer 7. IE6 was un-tested as of now."
This is only a problem for people who are violating one of the primary security policies in the first place, and that's putting your contact list in Gmail in the first place. While Google may claim to not be evil now, there's no guarantee at any time in the future, all the information they collect from you and on you won't be given or sold to other entities or otherwise exploited for nefarious purposes. In fact, it's pretty much an inevitability this will happen, so it's not smart in the first place to store much information on their systems when more secure alternatives already exist.
I posted this on reddit which broke the story earlier, and on my blog. Thought you might find it useful.
. txt
Quick follow-up. On digg someone posted the un-obfuscated code: http://www.cc.gatech.edu/~achille/contacts-source
How it works
The code is pretty straightforward. Basically, Google docs has an embedded script that will run a callback function, passing the function your contact list as an object. The embedded script presumably checks a cookie to ensure you are logged into a Google account before handing over the list.
Unfortunately, the script doesnt check what page is making the request. So, if you are logged in on window 1, window 2 (an evil site) can make the function call. Since you are logged in somewhere, the cookie is valid and the request goes through.
Also, if you check the object that is returned, you see fields for the contact's name, email and "affinity". Presumably, a higher affinity means a more-emailed contact, so it may be possible to know the relative weight of links.
Possible solutions
Google is run by smart people and I'm sure they'll have this fixed soon. A few suggestions appear to be popping up, all centered on making sure the user is on a Google.com page and not a random site:
Referrer blocking: Block all requests from sites not in the google.com domain. However, some people run referrer-blocking software. It may be the price they have to pay for security, but there could be other consequences.
Script checks: An idea I had was to check the window.location (just like you check the cookie) to make sure it's coming from a google.com domain. This is another way to see what page is making the request.
Challenge-response: Google pages (like Gmail) can have some token or unique, computed data that they submit with their requests. Random pages won't have access to this token when they make the function call.
(From user JRF on reddit): Include part of cookie in the request URL as a unique token that only a "real" Google page would know. Need to watch out for proxies/browser history (accessible from other pages) being able to access this unique data. May need to seed or salt it in a challenge-response system.
It's interesting thinking of fixes for this - do you have any other suggestions for how Google would fix this?
XML has no special cross-domain security over plain JSON.
JSON is not the problem here. The problem was the stupid google({}) function call wrapped around the JSON in the reply. Remove that stupid function call and everything is fine. Since you cannot receive or send data via XmlHttpRequest to a domain other than the one that served up the HTML, you will not be at risk if only JSON is returned.
The sky is falling!
The sky is falling!
Sheesh.