Hemmelig.app
Hemmelig.app copied to clipboard
Security audit
Feel free to audit this application. Would be highly appreciated.
Finding
Was able to bypass the mimetype restrictions by simply changing the Content-Type form header to something else. Example from the payload:
------WebKitFormBoundaryEQSxdNw95ZSUWTwh
Content-Disposition: form-data; name="file"; filename="MyCompressedFile.zip"
Content-Type: application/evilzip
This has been fixed in commit https://github.com/HemmeligOrg/Hemmelig.app/commit/cd7933345097a8aec1cbd68ffd98863773718508
Not sure if this is a big issue, but I did notice that when trying to view a password-protected secret, the password entered to unlock the secret is sent in clear text. This could be a possible attack vector for secrets with multiple views. Note that I'm not a security expert for MITM attacks ;)
@RainerZufahl, that is a fair point. Usually this is how passwords are handled by all kinds of applications. One could, however, of course hash the password before shipping it to the backend on creation. Not sure if the bcrypt library is possible to use in the frontend, but, could be looked into. Could off course use sha256 -> backend -> bcrypt -> redis. The salt could be the encryption key.
Of course, this scenario requires the server running the application to be breached (if not the server admin is the malicious one)
One other thought here is that if anyone has access to the server, they can inject logic in the frontend as well, such as key logging. This means they can get the secret.
The last thing to mention here is that even though the password is not in clear text, it will still be possible to use it to unlock the secret.
However, not a bad idea to implement hashing of the password, nevertheless.
Huh. I checked this on multiple high-profile websites, and you're right, they all send the password unencrypted. I suppose that's why HTTPS gained so much importance. I expected a MITM attack would suffice for breaching the password. But if HTTPS encryption can be trusted, separately encrypting the password before sending it might cause more headaches than it solves problems. I'll leave the final decision to you though ;)
Yeah, correct :) And, if you have an MITM attack, then you surely have other issues as well ;)