Varonis announces strategic partnership with Microsoft to accelerate the secure adoption of Copilot.

Learn more

The Dangers of Shared Links

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...
Rob Sobers
4 min read
Published June 11, 2013
Last updated June 30, 2023

Chain Links

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:

Google Drive Sharing Settings Dialog
Many applications aren’t nearly as clear as Google is in explaining to the end-user what it is they’re doing by creating and distributing a shared link.

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.

Rabbit stealing a cookie

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/

 

What you should do now

Below are three ways we can help you begin your journey to reducing data risk at your company:

  1. Schedule a demo session with us, where we can show you around, answer your questions, and help you see if Varonis is right for you.
  2. Download our free report and learn the risks associated with SaaS data exposure.
  3. Share this blog post with someone you know who'd enjoy reading it. Share it with them via email, LinkedIn, Reddit, or Facebook.

Try Varonis free.

Get a detailed data risk report based on your company’s data.
Deploys in minutes.

Keep reading

Varonis tackles hundreds of use cases, making it the ultimate platform to stop data breaches and ensure compliance.

spoofing-saas-vanity-urls-for-social-engineering-attacks
Spoofing SaaS Vanity URLs for Social Engineering Attacks
SaaS vanity URLs can be spoofed and used for phishing campaigns and other attacks. In this article, we’ll showcase two Box link types, two Zoom link types, and two Google Docs link type that we were able to spoof.
spoofing,-and-saas-vanity-urls,-and-social-engineering...-oh-my!
Spoofing, and SaaS Vanity URLs, and Social Engineering... Oh My!
Kilian Englert and Ryan O'Boyle discuss the recent discovery by Varonis researchers of risks in vanity URL validation, and share what to do to prepare your organization for if (or more likely when) a user accidentally discloses credentials.
using-malicious-azure-apps-to-infiltrate-a-microsoft-365-tenant
Using Malicious Azure Apps to Infiltrate a Microsoft 365 Tenant
Phishing remains one of the most successful ways to infiltrate an organization. We’ve seen a massive amount of malware infections stemming from users opening infected attachments or clicking links that...
share-permissions
Share Permissions
In one of our recent posts, What About Individual Users on ACL’s? I mentioned that some organizations have opted for using Windows share permissions instead of NTFS permissions for file...