A New Security Breach in Google Docs Revealed

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.

Comments

[Sean M. Price]

This security problem is something all SaaS customers must keep in mind when they outsource their applications. SaaS providers should also be mindful of the risk accepted by clients and undertake measures to ensure this type of vulnerability is prevented. The issue has been previously raised here http://blog.isc2.org/isc2_blog/2008/05/dare-we-outsour.html. Customer data is most likely commingled in the file system or database tables for most SaaS implementations. The only way to avoid this type of vulnerability is to ensure client content is in clear-text only when viewed in the browser. This means that all data transmitted and stored with the SaaS provider is encrypted with a key exclusively controlled by the end user. The Google vulnerability illustrates the risk of using SaaS and the ease with which trust can be quickly eroded. Storing sensitive information in clear-text on a system controlled by another entity is a risky proposition.

[Matt Simmons]

This is why I don't use Google Docs for anything critical. I keep my budget in there, but there aren't any personal details about account numbers, just amounts of money paid and owed. The next most important document is a "pie in the sky" spreadsheet that dictates how much money I need to put away every month to buy a sailboat and retire in 10 years.

It's great for sharing non-critical information, but I just don't trust "the cloud" for stuff like this yet.

I'm not sure what it would take to make me trust it.

[Tim Bass]

Dear All,

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, according to Google, they corrected their code that does not play well in cacheing scenarios.

Yours sincerely, Tim

[Stuart Moore]

It is a bad security practice to access any SaaS web site via HTTP. In this particular case, using HTTPS would have prevented the caching of objects by intermediate servers, but then again, we wouldn't have had this interesting blog post.

[Tim Bass]

Dear Folks,

Internet content caching is not an "excuse" for web-based security breaches. Web session code must be written in full knowledge that the objects will be cached in the Internet. So, it is not prudent to blame these types of security breaches on ISP caching (as some have done) the problem is in the web session application code, not the caching infrasture, at least in my view.

I am glad folks found this post interesting. Thanks for reading and commenting!

Yours faithfully, Tim

[Tim Bass]

Dear Folks,

I see our (ISC)2 blog was mentioned in SC Magazine:

http://www.scmagazineus.com/Google-Docs-flaw-could-allow-others-to-see-personal-files/article/116703/

Yours faithfully, Tim

[Eric O]

Great post!!

Google Docs is not very secure from this perspective. I wonder if similar problems are in Google Apps. I cannot believe Google has not implemented simple steps to prevent session-riding.

I hope this does not have implications for Google Apps.

[Mike Chelen]

RE: Sean M. Price 16 September 2008
"This means that all data transmitted and stored with the SaaS provider is encrypted with a key exclusively controlled by the end user."
Despite technical and performance challenges, all hosts and even Google must seriously consider how this may be accomplished.

[Ezabi]

It seems that the issue is not solved yet, it even gets worse :)
It was reported by a friend of mine this morning while using googlegroups, I haven't collected yet all the clues, but a report should be under way.
Can you give us a hint on what kind of evidence was enough for google to respond favourably?

[David Bern]

I emailed Google about this problem months ago. They said they'd look into it, but nothing has happened yet. So I've finally decided to post about it on my blog.

http://odie5533.com/?p=83

[Tim Bass]

Hi Mike,

Thanks for stopping by our blog.

The evidence I provided to Google was numerous screen shots of the breach, similar to the ones in this post.

Yours sincerely, Tim