« The value of online professional discussion fora | Main | A Different Kind of DoS Attack »

15 September 2008


TrackBack URL for this entry:

Listed below are links to weblogs that reference A New Security Breach in Google Docs Revealed:


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

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.



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?

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.

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.

Tim Bass

Dear Folks,

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


Yours faithfully, Tim

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

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 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

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.

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.

The comments to this entry are closed.

About the (ISC)² Blog

As the certifying body for more than 100,000 information security professionals worldwide, (ISC)² believes in the importance of open dialogue and collaboration. (ISC)² established this blog to provide a voice to certified members, who have significant knowledge and valuable insights that can benefit other information security professionals and the public at large.

The (ISC)2 blog gives members a forum to exchange ideas and inspires a safe and secure cyber world by supporting the advancement of the information security workforce via a public exchange with a broad range of information security topics.

Whether an (ISC)² member chooses to participate in the (ISC)² blog is his or her own decision. The postings on this site are the author's own and don't necessarily represent (ISC)²'s positions, strategies or opinions. (ISC)² monitors the blog in accordance with the (ISC)² Blog Guidelines, but the bloggers are responsible for their own content – common sense and intelligence should prevail.

Other than links to the (ISC)2 website, (ISC)² does not control or endorse any links to products or services provided in this blog and makes no warranty regarding the content on any other linked website.

Those who post comments to (ISC)² blogs should ensure their comments are focused on relevant topics that relate to the specific blog being discussed. (ISC)² reserves the right to remove any post or comment from this site. Should you find objectionable content in this blog, please notify us as soon as possible at blog@isc2.org

Please click here for FAQs.

Please click here for the Blog Guidelines.