Skip to content
This repository has been archived by the owner on Oct 11, 2020. It is now read-only.

Obsfuscate download URL! (metadata-leak) #61

Open
rugk opened this issue Jun 4, 2016 · 0 comments
Open

Obsfuscate download URL! (metadata-leak) #61

rugk opened this issue Jun 4, 2016 · 0 comments

Comments

@rugk
Copy link

rugk commented Jun 4, 2016

Currently one can download all the uploaded files by randomly trying (brute-forcing) URLs under /download, because only two letter/number combinations . As they are encrypted this is of course no big problem, but I still don't like it because it has one big problem: Metadata!

And after Snowden we should know that metadata matters.

So what one can get out by monitoring download:

  • File upload times
  • File deletion times
  • rough file size (both of thumbnail and original picture - with some intelligent combination of this data I could imagine one might get out the picture resolution or similar things)
  • very unlikely but when the random number generator is flawed attacker may get enough random data there to launch an attack and probably get out the encryption key
  • when you should change the cipher, version number or other things in the future one can also notice which are old files and new files and therefore can notice when img.bi was upgraded.

Of course if attacks against AES or the specific AES implementation are found you have also a serious problem, but when this happens you have a huge problem in general and this easy file access might be your smaller problem.
However a level of obscurity (which is achieved with more complex URLs in the download location) might at least prevent direct, easy attacks in this case.

So all in all: Please make the download location more complex, so one has to know the URL for downloading a specific file. Relying on the encryption is one way, doing everything to prevent attacks (including metadata leaks) is another...

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant