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."

Which is the problem?

So is this a Firefox, Gmail, or javascript vulnerability?

Re:Which is the problem?

Works fine in IE6. TFA states "I've tried the hack on IE7, Opera, and Firefox; it appears to be working on all three." so I'm not sure where the poster got the idea that it was Firefox only.

It's an information leak

http://docs.google.com/data/contacts?out=js&show=A LL&psort=Affinity&callback=google&max=99999 [google.com]

It can be exploit by writing a callback function in Javascript, that can do anything, and then passing it to the above link, which gives your function all the users contact info.

Re:Which is the problem?

GMail. JSON should not be used for sensitive data because any old website can reference it simply by including it as an external script. The Google developers should not have used JSON for this information, they did, and that is why this information leak exists. There are ways to protect JSON from this (e.g. nonces) but you have to actually add this security yourself, rather than relying on the browser's built-in cross-domain security like you could if you were using XML etc.

Re:Which is the problem?

It's a problem with web services that comes from an assumption that JavaScript cross-domain security is in place.

When you surface data via Xml web services, you can only call the web service on the domain that the JavaScript calling it originates from. So if you write your web services with AJAX in mind exclusively, then you have made the assumption that JavaScript is securing your data.

The problem is created at two points:
1) When you rely on cookies to perform the implicit authentication that reveals the data.
2) When you allow rendering of the data in JSON which bypasses JavaScript cross-domain security.

This can be solved by doing two things:
1) Make one of the parameters to a web service a security token that authenticates the request.
2) Make the security token time-sensitive (a canary) so that a compromised token does not work if sniffed and used later.

The security token should be gathered by authenticating the user according to a mechanism that the user controls. Think of the way that the Flickr API asks you to grant an application access to your data.

Anyhow, use the noscript extension in Firefox to ensure that your data is not compromised, as you will be able to choose to block the script from running, and in doing so prevent others from gaining access to your data.

The Internet Exporer alternative is to disable JavaScript, but few people ever do this because too few sites (especially Web2.0 sites) degrade gracefully when JavaScript is disabled.

Submitter has a problem with Firefox?

RTFA:
I've tried the hack on IE7, Opera, and Firefox; it appears to be working on all three.

Does the submitter have some agenda against Firefox?

Re:Submitter has a problem with Firefox?

It works fine in my install of FF 2.0.0.1; you have to be logged in to gmail for it to work. Despite what it says in the summary, it also works in IE7 - in fact, it'll work in any browser that

* supports cookies
* supports loading of resources from domains other than the one the currently-loaded page is hosted on
* supports accessing those resources

ie pretty much all (modern) browsers.

Phew!

We are lucky it was not Microsoft's Hotmail!

Works in most any java-script browser

According to the reports on Digg this hack works in all modern browsers. The real fix is probably to stop storing the contact list in a local java-script based file. (Or to always be sure to log out of Google after visiting a google page.)

http://www.digg.com/programming/GMail_Hacked_Visit _ANY_Website_and_Your_Whole_Contact_List_Can_be_St olen [digg.com]

Re:How does this work

No. Cross-domain xmlhttprequests are blocked by firefox at least, and I'd suspect by other browsers as well. The point is that you don't have to do a cross-domain xmlhttprequest here, since google conveniently stores it in a separate javascript file, and that is embeddable in other pages.

Re:How does this work

Here's the super simple explanation

1. Gmail sets a cookie saying you're logged in
2. A [3rd party] javascript tells you to call Google's script
3. Google checks for the Gmail cookie
4. The cookie is valid
5. Google hands over the requested data to you

If [3rd party] wanted to keep your contact list, the javascript would pass it to a form and your computer would happily upload the list to [3rd party]'s server.

At no point does [3rd party] make any request to Google.

Why do I bother with this site?

Slashdot says:

"So far the attack only works on Firefox, and doesn't appear to work in Opera or Internet explorer 7"

TFA says:

"I've tried the hack on IE7, Opera, and Firefox; it appears to be working on all three."

Got any jobs going? I could do nice armchair job at Slashdot. I'd be willing to work the full 3 hours a week.

Re:Why do I bother with this site?

I could do nice armchair job at Slashdot.

Not with that sentence structure. You only made one grammar error. You could never be a /. editor.

Thank goodness

Thank goodness. I was beginning to think that no one cared about my contacts.

Conceptual problem

Loading script files to exchange data with the server is a very common mechanism. It even has a name: JSON. It wouldn't surprise me to find that there are many more web applications which could be exploited in this way. This isn't a browser vulnerability or a simple bug. It is a design flaw of a widely used communication protocol.

Not valid JSON, is it?

I think the keys in JSON needs to be strings

Wow!

I'm glad that I run Firefox on Linux!

Oh wait...

Fixed?

According to

http://blogs.zdnet.com/Google/?p=434
it is fixed.

Not Fixed

Still works for me. You can run this script from a local html file to check:

<html>
<head>
<script>
function google(a) {
document.write("<ol>");
for (i = 0; i < a.Body.Contacts.length; i++) {
document.write("<li>" + a.Body.Contacts[i].Email + "</li>");
}
document.write("</ol>");
}
</script>
<script src="http://docs.google.com/data/contacts?out=js&s how=ALL&psort=Affinity&callback=google&max=99999"> </script></head>
<body>
Hello
</body>
</html>

Galeon too

just FYI, it works with Galeon (2.x) as well.

Can be solved with HTTP referer

I think it can be solved by Google checking HTTP referer [wikipedia.org] before sending out the contact list via JSON, as long as the browser does not use cached content.

The Web browser as application portal

These problems will not go away. Software engineers will always make mistakes and malevolent people will always want your private data. The Web is "open" by design and therefore open to exploits.

With the Web browser becoming an application portal, users need to understand that doing transactions that involve their personal data must be separate from general Web browsing.

You can switch off cookie permission and Javascript but this limits the functionality of many sites. I think the best solution is to use two different browsers, one for personal transactions, the other for wandering the Web.

Wow

C'mon, /. You're reporting this now? It's already been fixed [digg.com].

Don't volunteer that much info to Google

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.

GMail is beta

You shouldn't be suprised... as you all know GMail is still in beta.

Doesn't work in Opera 9.02

It doesn't seem to work in Opera 9.02, despite some people saying that it works on every browser. Either Google has changed something or the example code isn't working.

Explanation & Possible Solutions

I posted this on reddit [reddit.com] which broke the story earlier, and on my blog [betterexplained.com]. Thought you might find it useful.

Quick follow-up. On digg someone posted the un-obfuscated code: http://www.cc.gatech.edu/~achille/contacts-source. txt [gatech.edu]

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?

First link in the aritcle

I tried the first link in the article and I got a page with only this text: google ({ Success: false, Errors: [] }) It seems to not work. I'm using Firefox v. 1.5.0.9, and I was logged in to gmail at the time. Can anyone explain this?

Some details on how it works

It's a CSRF attack. For more details see this blog post http://getahead.ltd.uk/blog/joe/2007/01/01/csrf_at tacks_or_how_to_avoid_exposing_your_gmail_contacts .html#preview [getahead.ltd.uk]

not anymore

google has already fixed this problem

Fixed

It has now been fixed [browserden.co.uk].

What A Waste

This was a complete waste of a post! Unless its intent was to drum up some reader responses due to a decline in web activity which perhaps led to a decline in revenue for this site. Just thinking out loud.

My solution

I run gmail and other google services requiring login from a separate browser. Set the theme so this browser is visually distinct from your main browser. On Linux use a wrapper script to start with a different user. On Windows you can use K-Meleon (unfortunately, PortableFirefox cannot run in parallel with regular firefox).

Not perfect, but it works for me.

Re:Some Background Information

How is this relevant? Does this make him a terrorist?

Re:Some Background Information

First: What does this have to do with the subject at hand? Off topic. -1
Second: If you take
http://googlified.com.googlepages.com/contactlist. htm [googlepages.com]
and just strip the html page and go to:
http://googlified.com.googlepages.com/ [googlepages.com]
You'll find a link to googlified.com

Some things are so simple they're complicated I guess.