Slashdot Mirror
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."
So is this a Firefox, Gmail, or javascript vulnerability?
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?
My server
We are lucky it was not Microsoft's Hotmail!
http://www.digg.com/programming/GMail_Hacked_VisiIn illa quae ultra sunt
http://docs.google.com/data/contacts?out=js&show=A LL&psort=Affinity&callback=google&max=99999
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.
I'll probably be modded down for this...
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.
This post contains benzene, nitrosamines, formaldehyde and hydrogen cyanide.
Thank goodness. I was beginning to think that no one cared about my contacts.
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.
I'm glad that I run Firefox on Linux!
Oh wait...
http://blogs.zdnet.com/Google/?p=434
it is fixed.
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.
There are 11 types of people in the world: those who can count in binary, and those who can't.
just FYI, it works with Galeon (2.x) as well.
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.
[Fuck Beta]
o0t!
C'mon, /. You're reporting this now? It's already been fixed.
Lots of ways:
a. Place a 128-bit random number (UUID/GUID) into the URL for the contacts info.
b. Check the referrer. (foreign javascript should not be able to forge this)
c. Place an encrypted copy of the cookie into the URL of the contacts info.
d. Embed the contacts info in the page instead.
Still works for me. You can run this script from a local html file to check:
s how=ALL&psort=Affinity&callback=google&max=99999"> </script></head>
<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&
<body>
Hello
</body>
</html>
ENDUT! HOCH HECH!
You shouldn't be suprised... as you all know GMail is still in beta.
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?
Of course, by placing all your email in the hands of a company, you're undoubtedly taking a huge risk. But - perhaps unfortunately - it doesn't stop me doing it! I guess you have to hope that the huge amounts of bad will and loss of custom a company would get from using or distributing such information is incentive enough to leave well alone
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.