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."
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
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.
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...
Actually it is not stored locally in Javascript. I assume that the information is stored in some sort of filesystem / database and converted to Javascript on the fly to ease integration with other applications. You can also get the same information as XML if you prefer:
http://docs.google.com/data/contacts
I'll probably be modded down for this...
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.
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.
Why not? You're underestimating both how simple it is to spoof a referrer, and how stupid it is to use the referrer for security purposes.
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!
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.