Slashdot Log In
GMail Vulnerable To Contact List Hijacking
Posted by
Hemos
on Mon Jan 01, 2007 10:09 AM
from the in-special-circumstances dept.
from the in-special-circumstances dept.
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 discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Which is the problem? (Score:5, Insightful)
Re:Which is the problem? (Score:5, Informative)
Parent
It's an information leak (Score:5, Informative)
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.
Parent
Re: (Score:3, Informative)
Re:Which is the problem? (Score:5, Insightful)
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.
Parent
Nonsense (Score:3, Interesting)
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.
Re:Which is the problem? (Score:5, Informative)
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.
Parent
Submitter has a problem with Firefox? (Score:5, Informative)
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: (Score:2, Funny)
Nah, it was just a gag to get ppl to RTFA.
Re: (Score:3, Funny)
Re:Submitter has a problem with Firefox? (Score:5, Informative)
* 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.
Parent
Re: (Score:3, Informative)
Phew! (Score:4, Funny)
Works in most any java-script browser (Score:5, Insightful)
http://www.digg.com/programming/GMail_Hacked_VisiHow does this work (Score:2)
Re:How does this work (Score:5, Informative)
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.
Parent
Re:How does this work (Score:4, Informative)
Parent
Re: (Score:2, Insightful)
Re: (Score:2, Funny)
Re: (Score:3, Informative)
http://docs.google.com/data/contacts [google.com]
Re: (Score:2)
Re: (Score:2)
it ought to be fine (Score:2)
My browser should not grant this ability to random javascript it finds on the web.
nope (Score:2)
The spoof would have to work from Javascript or Java, creating connections on behalf of the user. Merely opening a TCP/IP socket won't do, because you'd not be able to shove the cookie down the wire.
Why do I bother with this site? (Score:5, Insightful)
"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? (Score:5, Funny)
Not with that sentence structure. You only made one grammar error. You could never be a
Parent
Speaking of grammar errors... (Score:2)
In other words, the submitter says that when a malicious website logs into Gmail and visits a website, it can steal my contact list.
Someone needs to learn how to use dependent clauses. The subject of the sentence above is a malicious website, and that's who is being described in the dependent clause as logging into Gmail and visiting a website.
Re: (Score:2)
Re: (Score:2)
Thank goodness (Score:4, Funny)
Conceptual problem (Score:5, Informative)
Re: (Score:2)
From what I understand, as long as the user has a valid cookie, the information is fair game... and I imagine that there are implementations that do not even bother with a cookie.
Maybe the question is: Can it be fixed?
per-site fix is obvious (Score:3, Informative)
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.
Re: (Score:2, Informative)
Not valid JSON, is it? (Score:2)
Wow! (Score:2, Funny)
Oh wait...
Fixed? (Score:4, Informative)
http://blogs.zdnet.com/Google/?p=434
it is fixed.
Not Fixed (Score:5, Informative)
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>
Parent
Re: (Score:2)
Galeon too (Score:2, Informative)
The Web browser as application portal (Score:2)
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 tw
Wow (Score:4, Informative)
Re: (Score:2)
(Yes, that's your own link. Read the discussion.)
Don't volunteer that much info to Google (Score:2, Interesting)
Re: (Score:3, Interesting)
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.
Whilst this is true, it's just the same as giving one's details to banks, credit card companies, phone companies, etc, etc ... they all have access to private and confidential information. I'm not sure that there's any more reason to suspect that they're any better or worse than Google - and judging from all the credit card snail-mail spam (from rival companies) that I've got since reluctantly obtaining a credit card, there's very good evidence to suggest that they wilfully share this info.
Of course, by p
GMail is beta (Score:2, Funny)
Doesn't work in Opera 9.02 (Score:2)
Explanation & Possible Solutions (Score:2, Interesting)
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
Re: (Score:2)
can't spoof it (Score:2)
Who wants to do the spoofing?
How is the spoofer going to get the cookie?
Right...