A New Security Breach in Google Docs Revealed

10
60
Google
Google

I am a big fan of Google and, over time, I have started to enjoy the freedom from my desktop with Google Docs. For example, when I keep track of business expenses I have found it easier to update a Google Spreadsheet versus depending on Microsoft Excel on my laptop because I can update from anywhere in the world and share with my bookkeeper too. So, I’ve been using Google Docs more lately.

Today, however, I discovered a huge security breach in Google Docs. While I was in my account working on a spreadsheet I suddenly found my Google Doc account listing many documents that did not belong to me. I clicked on one of the documents and the results are in the image below, where my Google Doc session appears to have “crossed over” with another users.

I decided to do a bit more exploring and take a few more screenshots, because I don’t yet know how to reproduct this security breach. The image below show a Google document (fifth from the top) which is not owned by me, “owned by me”. However, when I click on this mysterious “owned by me” document, it is owned by another user. Here is another screenshot below; you can click on the image for the full-screen version.

Again, here is another example of the same security violation with two documents. As above, you can click on the image for a full-screen version.

I contacted the owner of the Google Docs account which I had suddenly and mysteriously “crossed sessions” with today. I asked him if he was in Thailand (since a few of the documents were in Thai) and he said yes, however he say he did not have any Thai language documents in his account. However, as you can see from the screenshot, the Google Docs menu shows this person as “the owner” of a Thai language document. He also mentioned that, today, he saw “wierd documents” in his account that did not belong to him (or “normally” shared with him).

Unfortunately, I was having problems with the Internet connection in my hotel room so I could not continue to investigate the breach. When I logged back in a few hours later, everything was back to normal. So far, all is “normal” and I have not been able to repeat this breach.

I suspect the Google Docs flaw comes from a JavaScript error in how Google manages user sessions. The bottom line is that the security breach is real and dangerous. Your Google Docs, and I suspect other Google applications that use the same session management code, are vulnerable. There may be an underlying XSS vulnerability as well.

Note: Reposted from my original post on the ISC2 blog.

10 COMMENTS

  1. Could this have been an issue with the hotel’s web proxy somehow getting your session confused with another guest?

    Were you accessing Google docs over https?

  2. Hi Chris,

    No, the other user was not in the same hotel; but to be sure, I sent him another email to confirm where he was. (He was in a completely different city approximately 700 kilometers away.)

    Cheers.

    Yours sincerely, Tim

    PS: Sessions were not with SSL.

  3. It’s undoubtedly over-aggressive caching by a proxy, the caching headers are set correctly, but if a service provider wants to save a few dollars in bandwidth by slighting their users and disregarding the rfcs there is nothing physically preventing them from ignoring them. You can verify this by confirming the user is in a nearby geographic location.

    You should use ssl if you’re concerned your isp may be doing this, and email the administrator explaining the problem, it’s likely they just didn’t understand the impact of making their cache policy too aggressive. Unfortunately this is a general problem with the web.

  4. According to Google,

    “Thank you so much for providing us information about this issue. This issue should now be resolved. This problem occurred because of a unique issue on our end in combination with a local ISP.”

    So, it seems that Google corrected their code, or so they claim, that does not play well in caching scenarios.

  5. It has happened before due to a combination of factor including caching by local ISP. Hope that Google can continue to tighten this portion because frankly speaking, Google Docs is a great service.

  6. Caching is a “fact of life” on the Internet. Web session management code must be written in a way that assumes the Internet is not safe.

    In other word, the underlying problem is not proxy caches, but poorly written web session management code.that does not take into considerable that the web application has no control over proxy caching.

  7. Such errors are not always because of caching. This may be (and I believe it was) a problem with Google code. Similar problems have affected other Google services as well in the past e.g. Orkut where profile information from two users merged.

  8. Hi Abhi,

    Thanks for visiting.

    I agree with you.

    On the other hand, this error / security breach was the result of poorly written session management code in proxy cache environments.

    This was confirmed by Google engineers, who claim to have fixed the problem. On the other hand, Google engineers claimed to have fixed a similar problem months earlier, so it remains to be seen if the problem is completely “fixed”.

    Yours faithfully, Tim

Comments are closed.