
More Security Loopholes Found In Google Docs - vaksel
http://www.techcrunch.com/2009/03/26/more-security-loopholes-found-in-google-docs/
======
mustpax
Ok, I'm gonna try to address each of these "loopholes" one by one, because
this whole thing smells like fishy PR stunt (I'd say FUD, but HN ain't
slashdot right?):

1\. Non-private uploaded images: This is the image URL
<http://docs.google.com/File?id=dczjts34_227g3234gdg_b>. That looks like a
pretty secure random UUID to me. You have as much chance of guessing that as
guessing an account password. So the only problem here is revoking view access
for someone to the document after they have viewed it. They can keep accessing
the Document, _if they have a copy of it._ Which will always be true unless
you want to start serving DRMed PDF files or something. I wouldn't put that
past this particular security researcher.

2\. User can view earlier revisions of a diagram: Fair enough. Once again, it
doesn't seem like a complete breakdown of security if your collaborators can
view earlier versions of a document or a diagram within a document.
Personally, when I share a versioned document with someone, I expect they will
be able access the versioning information. I don't know if Google makes any
express guarantees about earlier versions being blocked off from viewers,
maybe they should, but it's worth making it explicit.

3\. Someone somewhere may be able to grant herself access to your documents: I
am not even going to address this one. Without an actual account of the
vulnerability, this is just irresponsible insinuation.

~~~
sounddust
I disagree with you about #1. There is no reason that serving these images
shouldn't go through the same authentication that accessing the document
requires (not DRM'd PDFs, just checking the cookies of the request for that
image to make sure the user is logged in and has access to the doc). Just
because they're available through a non-guessable URL doesn't make them
secure; there are dozens of ways that URL can leak without leaking the whole
document.

Also the fact that the image is permanently retained after the document is
deleted is completely unacceptable. It's obvious that they are trying to save
money on bandwidth and CPU here, but it's not an acceptable place to cut
corners.

As for #3, I think that it's pretty easy to guess what this vulnerability is.
It's probably the following: When you get an invite to view a shared document,
either 1) Accepting the invitation _after_ the document has changed and
permission redacted still gives you permission to see it 2) After your
permission is revoked, you can use that URL to regain permission to the
document.

~~~
tptacek
Re #3: that does appear to be the case. Create a document, edit it, add a
collaborator, verify they got the invite email (but don't sign in for it),
remove all collaborators, edit, save, then follow the invite; you'll see the
most recent copy of the document in the invite landing screen.

I disagree with you on points #1 and #2. A lot of very important web apps are
very insecure if crypto-strong nonce URLs aren't good enough. Clearly relying
on URLs is suboptimal, but it's a long way down from "suboptimal" to
"vulnerable".

~~~
sounddust
Well, in my view security is not a binary, nor is there a silver bullet which
renders all software secure. Security is a _strategy_ in which one implements
as many known protections as reasonably possible in order to reduce
vulnerability. In the Google Docs case, I think there is absolutely no good
reason not to authenticate HTTP request for components of a document that also
requires authentication.

Sure, crypto-strong nonce URLs are better than unobfuscated URLs, but that's
just one protection.

For example, let's say that Google accidentally leaks a directory listing of
all files on a particular google docs server (or let's say an access log, to
be even more realistic). If Google had properly authenticated access to these
images, then the leaked access log would be worthless and unexploitable.
However, without authenticating these requests, Google has suddenly caused a
mass security breach, as hundreds of people rush to wget all the URLs before
the images are taken down.

If Google is seriously expecting people to use their product as a replacement
for a business intranet, then they need to take seriously _all_ concerns.

~~~
jongraehl
Nitpick: a nonce is supposed to be used only once (safe against replay). I
think you both mean the URL is supposed to be secret. I agree that there are
many ways (e.g. web proxies) for a URL to become not-secret.

~~~
tptacek
I'm corrupting the term "nonce" regularly, but OK, I'll stick with "token". I
think "URL" leaves the mistaken impression that there is some way to pull a
Google doc out of thin air; something else has to have gone wrong for these
problems to impact you.

------
bcl
These recent problems with Google Docs highlight a bigger problem with keeping
your data 'in the cloud', you are trading security for ease of use and even if
you have the best development team in the world behind the app there are still
going to be leaks.

If your docs are inside your organization's firewall you have some assurance
that leaks can be discovered before everyone in the world has access. With
services like Google Docs all bets are off.

------
electromagnetic
Oh blah, blah, blah. The first two aren't major privacy blunders, they're
definitely not good but they already violate two long existing
recommendations. First, never upload a picture that you care if other people
see, so basically no compromising pictures. Second, if you're conducting
secret/illegal business, use a fucking pen and paper! The third isn't even
valid because he provides no proof.

> _"If that last claim turns out to be valid, I’m leaving Google Docs and
> never coming back."_

Ugh, there goes my respect for yet another TC writer. I really can't stand how
TC seems to have gone down the drain so fast, they used to be respectable but
now it seems like bogus semi-fraudulant article after another.

------
kwamenum86
These exploits sound similar to the recent Facebook photo exploit. Google
keeps information in redundant server farms so they can continue to server
billions of pages a day. Complex permissions usually do not mesh well with
this method of keeping data because it is impractical and maybe impossible to
use sessions or cookies to see if the user attempting to access a file has
permissions to do so. A (startup?) company could do a lot to solve these
problems by rethinking the way permissions work with distributed data. I think
the space is wide open and the market needs a better solution.

------
lsb
The bad thing about keeping your data in the cloud is that you don't really
know 100% if it's secure.

The good thing is that you all get security updates at exactly the same time
without doing anything.

~~~
dsil
Well, even if you don't keep it in the cloud you don't really know if its 100%
secure. And if you do "know" its 100% secure, you're wrong. So its just a
choice of who you trust more - google, your own company, some other company,
etc

------
neilo
Do these issues really warrant such an article? That closing statement was
pretty silly

------
chanux
If Free Software concepts spread in cloud, things will be better anyway.

------
TweedHeads
Enough of techcrunch mudslinging propaganda already!

What is HN becoming?

~~~
mbrubeck
Yeah, couldn't we at least link to the original blog post? The TechCrunch
writeup adds nothing.

[http://peekay.org/2009/03/26/security-issues-with-google-
doc...](http://peekay.org/2009/03/26/security-issues-with-google-docs/)

