2

I'm creating a file storage site and what I would do is just have the download links format as:

https://www.domain.com/[id]/[file name] //id would just be 1, 2, 3 etc.

Dropbox and many others have it similarly except that the IDs are long / hashed:

https://www.dropbox.com/s/23d3kaz4adw9deq/anyfile.txt

Is there any (security) reason behind for having it that way?

I was thinking maybe they do it like that so that people can't just increment the id by 1 and just download everything they come across which would result in unnecessarily losing of more bandwidth. But that is not the case, because both the ID and FILE NAME need to match, and file names aren't easily guessable.

3 Answers 3

6

Is there any (security) reason behind for having it that way?

Yes - a type of Security through obscurity - the files aren't really secure as the URLs are available without authentication, but it would make them reasonably private as they are not guessable. You would need more information (such as browser history logs) or some kind of brute force that would be unfeasible in this case.

I was thinking maybe they do it like that so that people can't just increment the id by 1 and just download everything they come across which would result in unnecessarily losing of more bandwidth. But that is not the case, because both the ID and FILE NAME need to match, and file names aren't easily guessable.

Aren't they? How about readme.txt, password.txt, untitled.bmp, CV.doc, etc.

Common word lists are widely available, and can be fed into a brute force program in combination with common file extensions and different IDs in order to execute an attack on your system. This is why it is a good idea to have a secure random component in your URLs.

2
  • 1
    So giving them not guessable IDs will make the files reasonably private in the sense that if the URL has not been shared nobody other than the owner should be able to access it? Jun 7, 2014 at 10:59
  • 1
    @KidDiamond: That's correct - you should of course use HTTPS if possible (and disable HTTP) which will stop the URLs being recorded in any proxy logs and prevent any MITM attacks from snooping the URLs. Also, you may want to secure your server/load balancer/firewall/etc logs as these may contain the hidden file URLs. Jun 7, 2014 at 11:40
2

Well, more than security (which you can achieve via other means, such as appropriate authentication), the issue is that when you have multiple front ends, you cannot easily implement a serial number, and scale, esp. if your service is also geographically distributed (either for disaster recovery or just location concerns).

Imagine a Dropbox-like service with thousands of storage servers, storing files, who is going to keep an index of what the current file # is? Even within the same account, you have the same problem with clients uploading files simultaneously.

The way to avoid that is to come up with URIs for the files such that the possibility of collisions is negligible. That is why systems such as SQL server have always supported both an auto-increment primary index, as well as a unique ID which was based on GUID. For folks who have worked on databases, we almost always used GUIDs unless we knew we would definitely have a single DB server, in which case having auto-increment was the best experience to have.

0

They are using the URLs as access keys because it's a lot easier to scale. Instead of looking up the file, then contacting a master database to check whether you're actually allowed to access the file based on another secret (a session cookie for example), they assume the URL is long and random enough that if you do know it you must be authorized to access it, without needing to query a separate authentication service.

The downsides are that it is not easy to revoke access to a file especially if they are cached (you'd have to wait for caches to expire) and URLs can leak more easily than passwords/session cookies because they are easily accessible in the user's history for example, and in enterprise HTTPS-intercepting proxies' logs.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .