Many web applications give users the ability to share private information with unauthenticated users via obscure, publicly accessible URLs. These URLs, often called “external links” or “shared links,” are a convenient way to collaborate with people without giving them a username and password.
Discover your weak points and strengthen your resilience: Run a Free Ransomware Readiness Test
But how in the world is it secure if the URLs are publicly accessible?
By generating a URL that isn’t hyperlinked, isn’t crawlable by search engines, and isn’t guessable by humans or computers (more on this later), you can be somewhat confident that only the people that have the shared link can access your data. It’s a form of security through obscurity.
You’ve probably come across the option to create shared links in many of your favorite apps like Evernote, Dropbox, Trello, Github, etc.
I really like the way Google Docs describes its shared link feature:
Sounds great! What could possibly go wrong?
There are a few critical factors that are essential to the security of shared links and the data they point to. The first is probably fairly obvious: we have to trust that the person we’re sharing with doesn’t expose the link to someone else, intentionally or otherwise. The second, which I mentioned earlier, is that the URL is so obscure that it is not guessable by a human or machine.
What exactly do we mean by obscure and not guessable? Much like we’re encouraged to have strong passwords, shared links need to be strong, too. We have to prevent someone from writing a script that attempts to access random web application URLs, hoping to find something valuable.
Enter: the GUID.
GUID stands for globally unique identifier. A GUID is a random 128-bit hexadecimal string that looks like this: 3F2504E0-4F89-11D3-9A0C-0305E82C3301. The idea is that GUIDs are so enormous that it is highly unlikely for two people to pick the same one.
How unlikely is it for someone to guess your shared link if it contains a random GUID? Put it this way: if you generate 1 billion GUIDs per second it would take you 36 years to produce a collision.
If your favorite web app created shared links that look like this, you’re in pretty good hands:
https://gist.github.com/rsobers/2016e57e0cb00c8e7a2d
So everyone uses GUIDs, right?
Eh, no such luck. There are some web apps that by default generate shared links that are simple and easy to guess (e.g., http://company.example.com/person/1234). I won’t name names. Needless to say, this is an awful practice and should be avoided.
However, a much less awful, but still dangerous, practice is to let users customize shared links. This is a feature that Box has and, recently, one of their users shot themselves in the foot by changing the default, unpredictable shared link for a sensitive document to something extremely easy to guess.
Box’s email response aimed at educating its customers was really well done:
The user was unaware of the implications of choosing the open access setting – meaning that anyone with the link was able to access it, anywhere on the internet. Custom links are easier for people to find than the random 20-character strings Box creates automatically for shared links, so it’s important to be aware of this potential risk and educate your users on when to keep access levels open or choose a different option like for collaborators only or for people within your company.
Amazon S3 also lets users name their own public buckets and, as Rapid7’s research has shown, not only will people use guessable names in their bucket URLs, they’ll also put loads of sensitive content there (hello, passwords.txt!) expecting it to be undiscoverable.
What are some other risks or concerns?
Robots.txt
Another misconfiguration that could expose shared links is on the application provider side. If the provider misconfigures their robots.txt file, which instructs search engines which paths not to crawl, and one of its internal application pages is inadvertently crawled by Google, you could see private information show up in public search results.
SSL Encryption
If the web app you’re using doesn’t use HTTPS for all requests, someone could sniff shared links off public Wi-Fi connections at Starbucks using something like FireSheep. Although, if the app doesn’t use HTTPS they could just steal your cookie and gain access to everything in the app, not just the stuff obtainable through shared links.
Access Auditing
Many cloud apps don’t give you an audit trail that shows you a history of who is accessing your shared links. This means that someone could be accessing your shared links without you even knowing about it. How do you know for certain that people haven’t discovered your shared URLs and are accessing your data regularly? Worryingly, you don’t.
Content Classification
Where is my sensitive data anyway? One of the things Box advised in its educational email was that users might want to disable public access for particularly sensitive data. But the fact is, with gigabytes or terabytes of data, most organizations have no idea what’s sensitive. Only if you know where your sensitive data is located can you take the extra steps to protect it.
Will cloud providers like Box and Amazon ever scan and classify content for you? I’m not sure, but it might be difficult given that they probably shouldn’t be looking at the contents of data that doesn’t belong to them (and might not even belong to you).
Link Destruction
What happens when someone leaves your company? Or maybe you just don’t want to share data with someone anymore. If they had full access to your system, you’d probably disable their username and password, but what if they make off with a few dozen shared links? Does your app have a way to expire or destroy these links so that they’re no longer valid?
Final Thoughts
Shared links are awesome. I can quickly share data with only the people I want to share with and I don’t have to clutter my user directory. But, while security through obscurity is better than nothing, it’s certainly not great protection. Couple that with the likelihood of user or admin misconfiguration through lack of understanding and poor user interfaces and, as we’ve seen with Box and Amazon, risk is high, so proceed with caution.
Photo credits (cc): http://www.flickr.com/photos/gozalewis/ and http://www.flickr.com/photos/texese/
