Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Security Businesses Google The Internet IT

GMail Vulnerable To Contact List Hijacking 139

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.

GMail Vulnerable To Contact List Hijacking

Comments Filter:
  • by Zaphod-AVA ( 471116 ) on Monday January 01, 2007 @11:12AM (#17422002)
    So is this a Firefox, Gmail, or javascript vulnerability?
    • by Stalus ( 646102 ) on Monday January 01, 2007 @11:18AM (#17422044)
      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.
    • by MarkByers ( 770551 ) on Monday January 01, 2007 @11:21AM (#17422072) Homepage Journal
      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.
    • If there is no problem for other browsers then obviously, there is something that FF needs to look into the thing.
      Now a days after releasing of FF I have heard lots of issues in between GG and FF. You may have seen the latest update for firefox 2.0 for the fixing of gMail. Wondering what could be the reasons.
    • by Bogtha ( 906264 ) on Monday January 01, 2007 @01:24PM (#17422884)

      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.

      • Nonsense (Score:3, Interesting)

        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.
        • by Bogtha ( 906264 )

          XML has no special cross-domain security over plain JSON.

          It's not XML that is special, it's JSON, because it can be parsed as JavaScript.

          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.

          You misunderstand, the whole point is that you don't need XMLHttpRequest if the data can be parsed as JavaScript. You just need to include it with a <script> element.

          • You misunderstand, the whole point is that you don't need XMLHttpRequest if the data can be parsed as JavaScript. You just need to include it with a element.

            Huh? I must be missing something big here, because I thought the whole point of XMLHttpRequest is so that you could easily query the server for data without reloading any pages or (i)frames. Lots of people get that data in XML format, others use plain text, and seems others use JSON. Whatever the format, you need XMLHttpRequest to get that data from
            • by mongus ( 131392 )
              You don't have to use XMLHttpRequest. You can dynamically add a script node to the document if you've got JavaScript you want to include from a different site.

              Here's an example [bluishcoder.co.nz].
          • It is very simple. The text google({"foo":"bar"}) is valid javascript when included and parsed via a script tag. The JSON text {"foo":"bar"} is not valid Javascript when included parsed via a script tag. It is a syntax error in Firefox, Mozilla, IE6 and every browser I've tried.

            I only mentioned XmlHttpRequest because some have incorrectly argued that you could still make an XHR call to a foreign website and get the raw JSON information. XHR prevents this with its site-of-origin policy. This bug was solely c
    • by buro9 ( 633210 ) <davidNO@SPAMburo9.com> on Monday January 01, 2007 @02:23PM (#17423374) Homepage
      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.
      • by appavi ( 679094 )
        Even with JSON it is possible to prevent these type of leaks. For the requests that contains sensitive data, send data only if the HTTP request method is POST. If it is GET, then simply give a 403. Third party websites can get javascript file/data from Google only through GET(using script tags, not with XMLHttpRequest). They can't make POST request because they will be prevented by same domain policy. Google applications can retrieve the data through POST method using XMLHttpRequest because they will be in
  • by CTho9305 ( 264265 ) on Monday January 01, 2007 @11:14AM (#17422014) Homepage
    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?
    • Indeed the current article is a bit light on details but it does say it affects the three main browsers - time to expect the barrage of "I'm glad to have switched back to IE7" posts from others that have not RTFA.

      The link to test out the vulnerability seems to be down.

    • Didn't work on Firefox when I tried it earlier today. Move along please ...
      • by Tim C ( 15259 ) on Monday January 01, 2007 @12:29PM (#17422504)
        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.
        • Oddly enough, it isn't working for me in Opera 9.10 in Linux, despite being logged in, and Opera (AFAIK) matches that criteria...
          • Re: (Score:3, Informative)

            by Tim C ( 15259 )
            Strangely enough, it's no longer working for me in Firefox (2.0.0.1, WinXP); I think google may have fixed the problem. Whether it's a real fix or an obscuration I have no idea.
    • by MattPat ( 852615 )

      To give the submitter the benefit of the doubt, perhaps he or she read the article as it only works on the third one.

      Or, the submitter works for Microsoft and is therefore required to make IE look spotless, lest a chair come sailing from the other end of the room.

    • Re: (Score:2, Funny)

      "Does the submitter have some agenda against Firefox?"

      Nah, it was just a gag to get ppl to RTFA.
  • Phew! (Score:4, Funny)

    by sorrill ( 968643 ) on Monday January 01, 2007 @11:16AM (#17422028)
    We are lucky it was not Microsoft's Hotmail!
    • "We are lucky it was not Microsoft's Hotmail!"

      i'm always happy to tell the tale of MS's FTC privacy bust in 2002. but there's a not so funny side to software vulnerabilities for the millions of poor slobs who aren't reading this thread, or any like it. i don't think the /. hardcore fully appreciate how skittish end-users have become about this stuff, esp since they can't tell fact from rumor, or javascript from egg nog (well, neither can i). step back and think about how the poor unwashed masses will feel w
  • by wnknisely ( 51017 ) <wnknisely.gmail@com> on Monday January 01, 2007 @11:19AM (#17422048) Homepage Journal
    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]
    • How can one page get access to another page's data? Javascript or not? Aren't pages that don't have a parent child hierarchy supposed to have no way to communicate (aside from same site cookies)? How does this work
      • by bberens ( 965711 )
        I suspect it works like the following:

        Google places a cookie on your browser which indicates you have authenticated to Google. The afflicted website makes the same exact ajax call Gmail does in order to download the contact information. Since your browser holds the appropriate cookie, Google happily obliges and hands your contacts information over to your browser. Google.com has no way of knowing that it was javascript from another site which initiated the request, the request is coming from your brows
      • by TubeSteak ( 669689 ) on Monday January 01, 2007 @12:26PM (#17422472) Journal
        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.
    • Re: (Score:2, Insightful)

      by Elentari ( 1037226 )
      Hopefully, one main difference between Digg and Slashdot is that the users here won't go and deliberately click the URL to watch their own account get hacked.
      • Re: (Score:2, Funny)

        by thopkins ( 70408 )
        Most users on Slashdot won't click any links, especially links for the articles on which they are about to comment. ;)
    • Re: (Score:3, Informative)

      by MarkByers ( 770551 )
      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 [google.com]
    • by Phil246 ( 803464 )
      Hrm, since the source requests the js file from googles servers, shouldnt it be possible to check the referrer to make sure its a google page?
      • by Sancho ( 17056 ) *
        That's trusting the client to send correct data. It's laughably easy to spoof the referrer.
        • Sure, I can hack the referrer to get into my own gmail account. Wooo, scary!

          My browser should not grant this ability to random javascript it finds on the web.
          • Re: (Score:1, Informative)

            by Anonymous Coward
            My browser should not grant this ability to random javascript it finds on the web.

            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.

            • by r00t ( 33219 )
              I spoof the referrer all the time, using the "wget" command. That does no good for attacking gmail though, because how am I to get the required cookie?

              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.
              • I don't know a whole lot about cookies, but wouldn't you think `wget` would provide a way to download them if you need to?

                • by r00t ( 33219 )
                  You can certainly get YOUR OWN cookies using wget. You may then use wget to break into your own account. You can even create defective cookies, which can be used for some fun at horrifically-designed web sites.

                  You don't get to run wget from within a browser belonging to somebody else, which is where you need to do the spoofing if you want to grab contacts info from somebody else.
  • by Inda ( 580031 ) <slash.20.inda@spamgourmet.com> on Monday January 01, 2007 @11:22AM (#17422084) Journal
    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.
    • by Headcase88 ( 828620 ) on Monday January 01, 2007 @11:33AM (#17422154) Journal
      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.
      • "By simply logging in to GMail and visiting a website, a malicious website can steal your contact list, and all their details. ..."

        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.
      • Not with that sentence structure. You only made one grammar error. You could never be a /. editor.

        Shouldn't that be "one grammatical error" or "one error in grammar?"
    • by jZnat ( 793348 ) *
      Don't worry, they'll get the story straight in the dupe.
    • Well, then, why DO you bother with this site?
  • by messner_007 ( 1042060 ) on Monday January 01, 2007 @11:26AM (#17422108)
    Thank goodness. I was beginning to think that no one cared about my contacts.
  • Conceptual problem (Score:5, Informative)

    by JackHoffman ( 1033824 ) on Monday January 01, 2007 @11:31AM (#17422148)
    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.
    • by sbben ( 983577 )

      It is a design flaw of a widely used communication protocol.
      Hey, this sounds familiar. SQL injection anyone?
    • This isn't a browser vulnerability or a simple bug. It is a design flaw of a widely used communication protocol.
      How do you fix it?

      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?
      • by r00t ( 33219 )
        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.
      • The problem is that the user has the cookie because he's logged into GMail (in a different window or tab, or he forgot to log out). The cookie which is sent with the request for the script is from the domain of the web app that the script is part of, not from the attacking website. One way to deal with this type of vulnerability is to check the HTTP referrer header, but since many users disable the referrer (mostly for privacy reasons), such a check would either not protect these users or prevent them from
      • by stevey ( 64018 )

        There is a simple fix, rather than making a request to a remote site which tests only your logged in cookie it should instead send a "random" value with the request.

        The way it works is:

        • Google sends the a form to you with a hidden "auth string".
        • When you make a request back you send the same auth-string/token with the request.
        • If the login cookie is invalid then the request is denied.
        • If the login cookie is valid and the auth-string was correct the results are sent back.
        • If the auth-string was missing the
    • Re: (Score:2, Informative)

      by zataang ( 596856 )
      Please don't jump to conclusions. As one of the comment above notes, cross-domain xmlHTTPRequests are anyway blocked by all the main browsers. The problem in this case is because of a particular way in which the data is stored by Gmail. Calling it a design flaw of JSON is stupid.
      • This is a design flaw in Gmail because it affects all of the browsers involved, right? It doesn't just affect one of them?

        Seriously, if this was an issue with all of the involved browsers, it would obviously be a flaw in Gmail. That's not the case.
      • Technically you're right: JSON is not limited to Javascript, even though the acronym means "JavaScript Object Notation". However, since JSON messages are by definition valid Javascript object definitions, it's not surprising that it's mostly used in the way GMail uses it: The page loads and executes scripts to move data from the server into the application on the client. This typical way of using JSON is prone to be exploited in the described fashion, unless the programmer has implemented additional securit
    • JSON is not the problem (the contact list could also be in XML or whatever other format), but the fact that Google hands out the contact list "script" based on cookie validation only. A simple referrer check should provide "good enough" security.
  • I think the keys in JSON needs to be strings
  • Wow! (Score:2, Funny)

    by repruhsent ( 672799 )
    I'm glad that I run Firefox on Linux!

    Oh wait...
  • Fixed? (Score:4, Informative)

    by prestonmcafee ( 923223 ) on Monday January 01, 2007 @12:08PM (#17422380)
    According to

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

    • me, at 843 hours (PST), using FF 2.0.0.1, the problem is not fixed.
    • Not Fixed (Score:5, Informative)

      by astrosmash ( 3561 ) on Monday January 01, 2007 @01:56PM (#17423132) Journal

      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 (Score:2, Informative)

    by phrostie ( 121428 )
    just FYI, it works with Galeon (2.x) as well.
  • 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.
    • That wouldn't help as the referrer can be spoofed: http://en.wikipedia.org/wiki/Referer_spoofing [wikipedia.org]
      • by moria ( 829831 )
        That hack needs the user himself to install suicide spoof extensions/plugins. Since we trust the users, it should not be a concern. Good to know the problem has already been fixed.
      • Who has the gmail cookie?
        Who wants to do the spoofing?
        How is the spoofer going to get the cookie?

        Right...
        • by yosofun ( 933530 )
          Who has the gmail cookie? ... js Who wants to do the spoofing? ... evilMan How is the spoofer going to get the cookie? ... ajax
          • by r00t ( 33219 )
            So you have a zero-day browser vulnerability that lets you see cookies from other sites. Good for you.

            Mind sharing?

            Your zero-day vulnerability is way bigger news than this gmail bug.
    • by jZnat ( 793348 ) *
      And to solve the cache problem, they send the "Cache-Control: no-store, no-cache, must-revalidate" header for that script.
  • 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 tw
  • Wow (Score:4, Informative)

    by Altanar ( 56809 ) on Monday January 01, 2007 @01:18PM (#17422836)
    C'mon, /. You're reporting this now? It's already been fixed [digg.com].
  • 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 st
    • Re: (Score:3, Interesting)

      by shellbeach ( 610559 )

      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

  • You shouldn't be suprised... as you all know GMail is still in beta.
    • Hmm, funny you would mention that. It seems to be a pretty stupid bug, but maybe this is why it is still in beta, not just because Google tries to get out of their responsabilities.
  • 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.
  • 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
    • by appavi ( 679094 )
      I have posted this solution [slashdot.org] earlier in this thread. Since you are asking I am posting it again. Easiest way is to filter by HTTP Request method.
      1. Check for the HTTP Request method. If it is POST, send the data. For other request methods like HEAD, GET send HTTP Status code 403(Forbidden).
      2. For Google applications, they should use XMLHttpRequest and POST method to retrieve the data. This will be allowed due to same domain policy.
      3. Unless otherwise specified, browsers does a GET request for a required reso
      • I agree with your comments, but a 405 (Method Not Allowed) HTTP status code would be an ideal choice rather than 403
        • by appavi ( 679094 )
          Thanks for your comment. I forgot about 405. 405 will be the appropriate status code in this case.
  • 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?
    • They fixed the javascript problem [google.com], but your contact list can still be accessed through xml [google.com] so, while the original problem that was found has been corrected, there's still other problems that work just as well, and probably many more yet to be discoverd ones.
      • by nwbvt ( 768631 )

        You mean probably many more yet to be published ones. Google (and the rest of us) will only find out about these if the person who finds them is nice enough to tell everyone. While I'm guessing most people in the world are nice enough to do that, its the few who aren't that I'm worried about...

        But I guess these security violations and performance problems and accessibility issues are all small prices to pay if you want a fancy "Web 2.0" website...

  • google has already fixed this problem
  • by linuxci ( 3530 ) *
    It has now been fixed [browserden.co.uk].
    • Not quite, that particular exploit has been fixed but the list is still freely available in XML form.
  • 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.
  • 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.

To invent, you need a good imagination and a pile of junk. -- Thomas Edison

Working...