
Google Drive Found Leaking Private Data - srikar
http://collaboristablog.com/2014/07/google-drive-found-leaking-private-data-warning-shared-links/
======
rishabhsagar
I didn't think "Anyone with link..." setting promised any kind of security.
Honestly, I don't think this was a 'security hole', more like a digital
equivalent of a home owner hiding house keys under the carpet, hoping no one
will look.

~~~
bradleybuda
That's not the issue. Let's say Alice shares a link to a Drive doc with Bob,
[https://drive/secretlink](https://drive/secretlink). If _that document_ has
an embedded link to Eve's website,
[http://some/thirdparty](http://some/thirdparty), and Bob clicks the link,
then Eve (as the administrator of the third-party site) will see the HTTP
Referer as [https://drive/secretlink](https://drive/secretlink), and she will
be able to access Alice's document.

~~~
macwarlock
I think rishabhsagar's metaphor of security through obscurity is indeed the
issue. If the secretlink protected only by the difficulty in guessing the URL,
and not an additional layer authentication for the person you are sharing it
with, then it amounts to hiding something (a key) in plain sight and hoping
for the best. Granted, I'm unsure if Google has a mechanism to throttle/block
attempts at guessing Drive URLs.

~~~
gus_massa
I expect that they have a throttling mechanism, but nevertheless ...

I just checked one of my shared documents. It has a 44 long “random” string,
it’s alphanumeric with a few symbols. It looks like a version of base64, but
let’s assume that it has only 50 characters to choice, so there are 50^44 =
5.7E74 possible addresses (2.9E79 if we assume base64). (Assuming they are
using something like a cryptographically secure pseudorandom number
generator.)

There are 7E9 live person, and assume that each one share less than 1000
documents, so there are less than 7E12 used addresses. Only one in 5.7E74 /
7E12 = 4.2E66 address has a document.

For a brute force attack, lets assume that the attacker use each valid ipv4
address 256^4 = 4.3E9 to do 1000000 tries per second, so there are 4.3E15
tries per second.

So the expected time to guess an address is 4.2E66 / 43.E15=9.8E50 seconds,
that is 3.1E43 years. (For comparison, the universe is only 1.4E10 years old.)

~~~
TheLoneWolfling
That's in the ideal "system is performing exactly as intended" case, though.

You're assuming that there isn't, for example, a timing attack on the string
comparison function. And it doesn't have to be just their server either. It
could be, for example, an intermediate proxy server that leaks timing
information.

~~~
gus_massa
Yes, I suspect the more probable leaks are dew to malware and mistakes
(someone want to post a kittens picture, but he makes a mistake and paste the
doc url.)

And your comment is interesting. Are the proxy servers expected to be secure
against a timing attack?

(Also, the proxy administrator may be able to see the logs ...)

------
nly
HTTP referers are evil. I've been using RefControl[0] to block 3rd party
referers for years now.

[0]
[http://www.stardrifter.org/refcontrol/](http://www.stardrifter.org/refcontrol/)

The web wasn't built with privacy in mind. 3rd party cookies and HTTP Referers
are just the low hanging fruit.

~~~
grannyg00se
Why do you consider them evil? It's useful for a destination server to be
given insight into the previous url and it doesn't expose any private
information.

I suppose one might consider their previous url private information, but if
that's the case you've go a lot more to worry about than http referers.

~~~
Dylan16807
More to worry about, such as?

URLs aren't protected any less than cookies are, and cookies are the standard
way of securing login tokens.

Heck with URLs you get the 'secure flag' cookie option for free!

~~~
tiglionabbit
Yes they are. Cookies are subject to the same origin policy. The Referer
header is not.

~~~
Dylan16807
I think you misread. grannyg00se said there is a lot more to worry about _than
http referers_. We don't need a reminder that referer is a problem.

------
eli
I'm glad Google fixed this, but if something is important you really shouldn't
be securing it merely by giving it an obscure URL.

Google Drive makes it very easy to say "only these named people" should have
access, or "only people who have the link AND a google account for your
company"

~~~
benihana
> _" only people who have the link AND a google account for your company"_

I'm not on my work computer, but I can't remember there ever being an option
for only let people with a company google account see this. If that was the
case, why wouldn't that just be on by default (which I would argue is
everyone's expected behavior on corporate google drive).

~~~
sharth
So, if I attempt to share a document, I have these options available to me:
[http://imgur.com/efTUXgY](http://imgur.com/efTUXgY)

They include:

    
    
         Public on the Web
         Anyone with the link
         lynch.us
         People at lynch.us with the link
         Specific people
    

Additionally, if I goto
[https://admin.google.com/AdminHome#AppDetails:service=Drive+...](https://admin.google.com/AdminHome#AppDetails:service=Drive+and+Docs&flyout=sharing),
I have the abilitiy to the set the domain-wide default sharing settings. As
seen here: [http://imgur.com/RL0eUhZ](http://imgur.com/RL0eUhZ)

------
Zigurd
Google is correct to say this is a relatively obscure issue, and a relatively
small increment in loss of security. Who would consider sharing a Drive link
to be "secure" by any definition of the word? It can leak all over the place
by numerous means. For starters, and email recipient of the link might be
using an unencrypted connection for downloading the link over wifi.

------
onion2k
That's a very poorly worded security setting. If you're building a service
where people can share something set as "Anyone with link...", you really
ought to make it very clear that means it's open for anyone to download. The
setting should really be named 'Remove privacy settings - allow anyone to
download'. 'with link' implies some level of security that just isn't there.
Even if Google proxy links within the document, there's _always_ the
possibility that someone could accidentally send a link to the file to
someone, or that someone could shoulder surf it, or even guess it is if it's
simple enough.

~~~
fixermark
I've always thought of 'Anyone with the link' as functionally equivalent to
'Anyone.' I will continue to think so after this referrer-header change.

The first time you email that link out, you have technologically released your
ability to predict who will view the document (was the e-mail sent over secure
channels end-to-end? Did it go to a trusted party who won't reshare it? Did
you typo the e-mail address and send it to an undesired party? Did a recipient
print it out and leave a printed copy lying around in an accessible conference
room? Was the printout shredded after use? Was the shredding functionally
irreversible? Is the shredding being done by a third-party that might lose
some loads of documents on the way to the shred facility? Did you leave the
link in your local machine's pastebuffer then walk away without locking your
terminal? Etc., etc., etc.).

Even when the link is functionally unguessable, allowing non-authenticated
access is just "security through obscurity."

~~~
timothya
It provides as much security as you have trust in the people you share it
with. If I set one of my documents to "anyone with the link" just so that I
can access it when I'm not logged in, and I'm careful to not share the link
with anyone else, then I'd argue that it's still provides some security
because I trust myself.

If I shared a document with only you (directly, not using the "anyone with the
link" permission), I couldn't stop you from taking a screenshot and sending
that to whomever you pleased (or printing them out and leaving them in a
conference room, like you suggested). Sharing documents online in general can
be troubling if you don't trust the people you send them to. It's easier to
share a link than share a screenshot, though, and a link would provide
continued access going forward, and could remove deniability that the
screenshot was faked.

~~~
fixermark
But without authentication, there's no way to know if the people who claim to
be the people one shared the link with to be the people one actually shared
the link with.

Whole-document transformation and copying are a concern, but I think that's
usually treated as a different category of issue from "The server I trust to
store the data securely gave it up to some anonymous person who passed a
correctly-formatted request to it because the server can't know any better."

~~~
timothya
Yes, certainly this particular bug was serious and a real problem that needed
to be fixed. The link should not be shared accidentally like that.

I was just making the case that "Anyone with the link" still provides some
security. Just like you don't know if the people accessing the document are
the ones that you shared the link with, you don't know that the people you
shared the document contents themselves with aren't showing others without
your knowledge.

------
lazersharks29
> "The security hole, which has now been patched by Google"

This has only been fixed for _new_ links. All existing links are still
vulnerable.

From Google's Blog:

>"Today’s update to Drive takes extra precaution by ensuring that _newly
shared_ documents with hyperlinks to third-party HTTPS websites will not
inadvertently relay the original document’s URL."

~~~
timothya
To clarify, I think what they mean is that it's possible that those old links
have already been compromised, even though none of the documents (new or old)
are vulnerable anymore.

The bug has been patched so that any document with the "anyone with the link"
permission will no longer leak its location in the referrer when someone
clicks an HTTPS link in it. But it's possible that that happened in the past
and the link was already leaked (and unfortunately, they can't exactly fix
that). So if you have an old document, it's not vulnerable _anymore_ , but it
may at one time have been vulnerable so you might want to update it to have a
new link (following the instructions in the Google blog post).

~~~
lazersharks29
That's still pretty bad, there could be millions of leaked document URL's in
the logs of severs all over the internet and users haven't been notified.

It looks like Microsoft Onedrive did a similar thing too:

[https://blog.onedrive.com/update-for-shared-
links/](https://blog.onedrive.com/update-for-shared-links/) >"We chose _not to
disable_ all previously shared links, because the change only applies to a
small fraction of shared files. If customers disable and then re-share a
document, this will prevent further access to a document that might have been
accessed."

~~~
unreal37
Highly doubt it's millions. You have to upload a non-native format into Drive,
modify the default security settings, and be linking to another HTTPS site and
someone has to follow that link. AND the information in the original document
has to be sensitive. The odds of that are very, very low.

------
burstworks
Maybe I'm misunderstanding, but if the document in Google Drive is served over
HTTPS, then the referrer when a user visits a linked site should only show the
hostname (ie drive.google.com) not the full URL, right?

------
sp332
How does the fix work? Does it prevent the browser from sending the referrer
URL? Or maybe load all documents from the same URL with the document ID in a
POST request instead or GET?

~~~
aiiane
Normally most outgoing links that are meant to be private are bounced through
a redirection that results in the referrer being a generic Google redirection
page. That's probably the solution that was applied here.

~~~
sp332
But it says this was only a problem for documents that were not converted to
Google Sheets etc. I don't think editing everyone's PDFs and every other kind
of document that has clickable URLs is the easiest way to solve this.

~~~
dlgeek
Looks like it only applies to a "Preview" feature, so I imagine they're
already parsing the contents to render the preview and are either adding a
redirect or a no-follow attribute.

Native-native docs wouldn't have a referrer because they wouldn't be rendered
by the browser, so links would be a direct hop.

------
me_myself_and_I
How is this different than DropBox? Maybe dropbox is more obscure and google
more open, hence finding this vulnerability is actually a good thing. Just
thinking aloud.

~~~
pacaro
Dropbox posted a blog article about their approach to this issue in May —
[https://blog.dropbox.com/2014/05/web-vulnerability-
affecting...](https://blog.dropbox.com/2014/05/web-vulnerability-affecting-
shared-links/)

Disclaimer: I work for Dropbox

------
meritt
[https://www.facebook.com/notes/facebook-
engineering/protecti...](https://www.facebook.com/notes/facebook-
engineering/protecting-privacy-with-referrers/392382738919)

Facebook Engineering's entry on various methods of hiding referrers. This was
4 years ago, so some of these techniques might not still work.

~~~
retroencabulato
Wow, don't read the comments on that blog.

------
Synergyse
Anyone with the link could also share the link publicly. I think if your
document contains sensitive information you should be restricting the access
anyway.

------
jflowers45
I've always wondered what percentage of people understood what "anyone with
the link" meant as a security setting.

------
logn
I think the referrer info itself is a security hole. Browsers should disable
it. Or, you can use a plugin for now.

------
msutherl
Thousands of people working in enterprise are being banned from using Google
Drive right now.

------
tanglesome
This is news? Come on! You give anyone a link to your data and you expect
security! Hello! If I gave folk a key to my house I doubt I'll have any my A/V
equipment or computers when I come back after a long weekend. Why should I
expect my data to be any safer!?

~~~
coldtea
> _This is news? Come on! You give anyone a link to your data and you expect
> security!_

Yes. I expect security from my bank, from my insurance company, from state
agencies, from my email provider, etc. I surely don't expect them to leak my
data, and if they do, cause of a bug or incompetence, I want them to fix it.

And I want to be informed when they have breaches or fail to secure my data.

> _Hello! If I gave folk a key to my house I doubt I 'll have any my A/V
> equipment or computers when I come back after a long weekend._

People hire babysitters, cleaning stuff etc, give them the key to their house,
and expect to have their A/V equipment when the come back.

If a cleaning person is reckless, and e.g leaves the door unlocked when he
leaves, or a babysitter brings her pals over and have a party with my stuff,
they get fired and/or sued, and people hire a more trusty person. Businesses
that want to keep our private data should be kept to the same, or actually
much higher, standards.

The "helloooo, is this news, of course it's unsafe, whaddaya expected" etc
attitude doesn't help raise the bar on data safety.

~~~
jpetersonmn
> The "helloooo, is this news, of course it's unsafe, whaddaya expected" etc
> attitude doesn't help raise the bar on data safety.

I would think just the opposite is true. Perpetuating the idea that "Anyone
with a link" means anything other than "Anyone" doesn't help raise the bar on
data safety.

I'm glad Google made the enhancement to this, but wouldn't classify it as a
security issue.

