Is random URL token secure enough for file attachments and other user content?

Question

Lets say we have a hypothetical system where there are various files are added by users and are sensitive, e.g. lets say an attachment to a private message. It's not that easy to verify access rights usually (in terms of implementation), since attachment can be added to multiple objects, etc. So a common way to implement it is something like that:

mysite/file?id=DFD-...FDFD

Lets say that the id that is used is generated using secure PRNG (not a guid or something) and it's virtually not possible to guess. Will that provide adequate security or the risk of the URL exposing is rather high?

Possible problems include users exposing these urls, so it does not seem very secure even with non-guessable urls to me if the attachment can contain any sensitive data, but it's interesting to know the thoughts of security experts on that.

P.S. I have found this URL on github where this exposure was a real case. A developer thought that URL is protected and published on a public place but it appeared to be not the case.

Answer 1

While it definitely does provide a degree of security, it still leaves you a number of security holes that may or may not matter dependent on the type of application you are developing. For a non-exhaustive list:

• Content may meant to be limited to a select group of users, what if one of them leaks the URL?

• URLs with GET parameters are stored in a large number of places - web history for example

• Occasionally you see major issues when google crawls things they are not meant to, for example the instawallet fiasco.
• Security vulnerabilities elsewhere in your site may expose the links, and with no additional security they will be exposed.

If I were you, I would want to implement additional security by tying files to specific people/groups who may be able to access it, and confirm their session prior to serving the content.

Answer 2

Use of long random tokens as secrets to provide access to a file can provide effective security. I'd recommend 128+ bits to make it truly outside the range of randomly guessing. You could probably get away with fewer bits, especially if you rate limit IPs based on bad guesses. E.g., if you had a 64-bit or 80 bit token and a billion such files and were attacked by a botnet with a million distinct IP addresses that each could each try 10 guesses every 10 minutes -- say you banned an IP for 10 minutes after 10 incorrect attempts, it would take them about 12 days (64 bit token) or 2300 years (80-bit token) to find a single random file.

However, to do this in a secure manner you should keep some caveats in mind:

1. Use HTTPS. Network eavesdroppers can see (or secretly alter) any traffic over HTTP.
2. If the document has links to other webpages and a user clicks said links, the web-server at the other end will generally see a HTTP Referer header in the HTTP request which will provide the full URL (including any secrets; this is even if the secret is in a query parameter like https://www.google.com?q=secret ) and will still happen if the user is in private browsing mode.
3. The random token probably may be stored in your computer browser's history (unless you browse in private mode and end your session).
4. Some search engine gets hold of your random token and indexes it.
5. The mechanism for informing the user of the key possibly leaks it to third parties. Email is potentially exchanged unencrypted and if you use an third-party email provider your secret key is accessible to administrators at that email provider. Many users also save plaintext email to their computer with an unencrypted disk (e.g., the hard drive may be removed or someone boots into a live cd to read the disk's contents) or leave the computer logged into their email account.

Issue 4 can be usually avoided by maintaining a robots.txt and forbidding a directory.

User-Agent: *
Disallow: /private/

You can mitigate issues 2 and 3 by requiring the user to request their document by HTTP POST (over HTTPS). That is instead of clicking a link like:

<a href="https://example.com/private/LfliQdgOAkjs9H0Oi5ZZcw">File</a>

You could do something like embed the following in a HTML email:

<p> Click the button below to get your file:
<form action="https://example.com/private_file/" method="post">
  <input type="hidden" name="token" value="LfliQdgOAkjs9H0Oi5ZZcw">
  <input type="submit" value="Get File">
</form>
<p>Or go to https://example.com/private_file/ and cut and paste the token <pre>LfliQdgOAkjs9H0Oi5ZZcw</pre>.

This would prevent the secret from appearing in your browser history or receiving referer links (as the URL would simply be https://example.com/private_file/).

Alternatively, you could allow links of the form https://example.com/private/LfliQdgOAkjs9H0Oi5ZZcw, but then redirect the user to another URL when actually serving the private https://example.com/private/document. This would prevent issue #2 with Referer headers, but still may leave the link in your browser history.

Answer 3

These types of questions come up from time to time.

Essentially, this is security by obscurity.

The fact that it is hard to guess only addresses one type of issue. It does not protect against:

• Users accidentally sharing the link, bookmarking the link, etc.
• The user accidentally typing the url into Google or another search engine, resulting in it being indexed.
• External monitoring or network traffic interception, caching

You may be interested in this example with DropBox and similar from a few years ago:

The vulnerability was discovered by cloud-based file locker Intralinks in a Google AdWords campaign in which its services are advertised using keywords that identify its competitors, which in this case are Box and Dropbox. The vulnerability exists when users share files via share links, which are then subsequently inserted into the search box (as opposed to the URL bar) in their browsers; this allowed Intralinks to collect the data in the AdWords campaign management interface.

In the same fashion, users are vulnerable to a slightly different attack that involves the relay of HTTP Referrer headers, as Dropbox outlines in this example scenario:

A Dropbox user shares a link to a document that contains a hyperlink to a third-party website. The user, or an authorized recipient of the link, clicks on a hyperlink in the document. At that point, the referrer [sic] header discloses the original shared link to the third-party website. Someone with access to that header, such as the webmaster of the third-party website, could then access the link to the shared document. In the same post, Dropbox notes that the problem with the search box is "well known and we don't consider it a vulnerability." Ultimately, the only protection that the shared files have is that they are difficult to get to, requiring an exceptionally long URL to access — in effect, security through obscurity.

---

Putting a picture in front of a safe is not the same thing as locking the safe...

It sounds like you are trying to avoid implementing real authentication. You may want to look into implementing real access control (authentication and authorization) as well as something like information rights management.

At the very least you could ask for some code, token, or identifer when the file loads as a gateway before providing access. E.g., you send the link by email and they can only get to the actual file once they enter their email again. Provides some protection against accidental indexing, but not other cases.