0

This question already has an answer here:

I'm trying to create a simple download system as a part of my website. Is there anything insecure in this route:

 GET https://my_website.com/downloads?file_id=AAA&user_id=BBB&secret=CCC

Where user_id and code are optional for files that are free to download. Otherwise, after a payment I generate a unique code/secret for a user and provide him a link.

Is there room for improvement here? And are there vulnerabilities?

It's not just a random url

There'll also be "expire_date" associated with each secret.

marked as duplicate by Anders, M'vy, Steve, Xander, AJ Henderson Oct 19 '17 at 15:59

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • I think there are more duplicates out there if you search for "random url" or "unguessable url". – Anders Oct 18 '17 at 6:52
1

A few thoughts:

  1. URLs get logged and remembered all over the place (server and proxy logs, browser history, search crawlers, etc.), so unless the link is very ephemeral (short-lived), you should assume the links will leak and can't be used to provide a lot of security. If you want actual authentication, you should either set a cookie (securely) and reject requests that don't have the expected cookie value, or transmit the secret fields in a POST body, or otherwise keep the secrets out of the URL.
  2. Obviously, the user ID and secret need to be unguessable. That means they need to be long, and securely random. As a general rule, aim for at least 128 bits of entropy; this is more than you strictly need, but it's cheap and may offer some protection against weaknesses elsewhere (though it also may not).
  3. I'm actually not sure why you're bothering with a user ID, here; unless the user ID is a reusable identifier that the user gets value out of having remain constant, you may as well just use the secrets.
  4. The file ID, rather than file name, implies that you're not actually having anything the user provides be directly used to build a path into your file system. This is good and right and proper. Do not, if you can help it, provide a way for users to ever specify the names of files directly, as that risks the users gaining access to files you didn't mean them to access.
  5. You might want to create a time limit, usage limit, or revocation system for your secret links. Otherwise, once a link is generated, it will stay valid forever even if you want it to stop working (or the user wants it to stop working, for example because it links to something sensitive/private to the user but somebody got their hands on the link).
  6. If you have to manually process payments and generate links, that won't scale. Doing it automatically is entirely possible but requires a lot of work to make the payment handling and verification secure.
  7. Make sure you're validating the parameters securely. Watch for injection attacks (for example, SQL injection if you're checking against a relational database) and sanitize the fields if you ever reflect them into the page (to prevent cross-site scripting), especially if you use cookies or local storage for anything.
  8. Can users also upload files? If so, you've got a whole mess of stuff to watch out for, everything from preventing users from uploading malicious or illegal content to ensuring that users don't overwrite important files (potentially gaining control over the webserver) or make the server spend a ton of resources trying to process a really expensive file (like a compression bomb).

I'm sure I'd come up with a lot more, but that should be enough to get you started. Security is hard. Trying to make your security system simple doesn't mean it's easy to get it right.

  • Otherwise, once a link is generated, it will stay valid forever even -- I'll add "expire_date" – Uji Oct 18 '17 at 8:50
  • The file ID, rather than file name, implies that you're not actually having anything the user provides be directly used to build a path into your file system. -- but it'll allow a hacker to do the enumeration attack and find out how many files there are – Uji Oct 18 '17 at 8:51
  • users will not be allowed to upload files – Uji Oct 18 '17 at 8:51
  • No need (or reason) for file IDs to be sequential. Figuring out how many files there are probably isn't a significant weakness, but why take the risk? – CBHacking Oct 18 '17 at 9:08
  • what risk?............ – Uji Oct 18 '17 at 10:11

Not the answer you're looking for? Browse other questions tagged or ask your own question.