1

For example https://s3-eu-west-2.amazonaws.com/mybucket/620f5cb4132cf1b4619503ece569599e

This is a private file, I send to the web-browser through https link to that private file - but this file is publically accessible by this link. Should I add auth using header information that S3 will read? But I think that if somebody will take this link from memory - attacker also can steal a header too.

Name of file - md5 of content that was generated for that client. Also after one day this file will be automatically deleted.

UPDATE: in the normal workflow user will neither see nor operate in any way with this links - but can find them in developer tools of the browser.

UPDATE 2: thank you for related links, I read them, yes this questions quite relative, but specific of this question: 1) public files on Amazon S3 2) User do not see urls.

UPDATE 3: reading related questions I found possible scenarious:

1) Browser crash can send url to the third-party server (I am not sure but sound realistic).

2) User install some anti[virus]/proxy that send all HTTP call endpoints to the third-party servier (not sure about this too).

Vitaly Zdanevich
  • 117
  • 7
  • *Is it secure?* is not a good question here. Security is not absolute but relative to a threat. What are your security requirements? – Serge Ballesta Jul 06 '17 at 13:09
  • A more direct duplicate: [Is including a secret GUID in an URL Security Through Obscurity?](https://security.stackexchange.com/q/36870/12) – Xander Jul 06 '17 at 13:20
  • One more dupe: [Are secret URLs secure over HTTPS?](https://security.stackexchange.com/q/33738/12) – Xander Jul 06 '17 at 13:21
  • @SergeBallesta security requirements: this content belongs to the user and only user must have the ability to get it. – Vitaly Zdanevich Jul 06 '17 at 13:51

1 Answers1

1

If it's intended to be a private file - it is not a good idea to leave it open to unauthenticated public access.

While the design of the public URL generation itself may make it impractical to discover it, depending on how you share it with your target audience, the links could be shortened - and the shortened links could be discovered much more easily not only through bruteforcing but also through insecure methods of sharing.

There was a research done less than a year ago (I need to look it up again for references) - where researchers found that bruteforced shortened links often resulted in files of this nature - open for unauthenticated public access, depending on obscurity.

Sas3
  • 2,638
  • 9
  • 20
  • But what if in normal usecase user will not see this links without opening the developer tools of the browser? – Vitaly Zdanevich Jul 06 '17 at 12:20
  • Any link shortening service will use a 301/302 redirect - and then the long URL will show up on the browser. No need for developer tools. The point in any case is that there are people out there - who are not normal users; who have the skill & motivation to use the developer tools; and who were known to be routinely trying random shortened links. If you've exposed your long URL to any of the shortening services - either explicitly (e.g., bit.ly) or implicitly (e.g twitter DM), then there is a non-negligible risk. Of course, you could accept the risk and move on. :) – Sas3 Jul 06 '17 at 12:47
  • But what it I do not use any url shortening service, implicitly too? this link returned from POST. My thoughts are if somebody open devtools to get this link - it is mean that this bad guy already sees the content of user from which this link to this processed private content was generated. I do not want to complicate my code without correct security reason, and now I do not understand the scenario that I need to protect. – Vitaly Zdanevich Jul 06 '17 at 13:48
  • It seems that "attacker in a privileged position (on the client, scraping memory / MITM, sniffing headers) is the only threat scenario. In view of the other limits to exposure (auto delete after 1day, no other URL-info-leaks), accepting the risk seems okay, especially if implementing any form of access-control is too expensive. – Sas3 Jul 06 '17 at 14:02