Hemmelig.app icon indicating copy to clipboard operation
Hemmelig.app copied to clipboard

Security audit

Open bjarneo opened this issue 3 years ago • 5 comments

Feel free to audit this application. Would be highly appreciated.

bjarneo avatar Jun 13 '21 18:06 bjarneo

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

bjarneo avatar Aug 22 '22 17:08 bjarneo

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 ;)

bytebone avatar Sep 14 '22 15:09 bytebone

@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.

bjarneo avatar Sep 14 '22 20:09 bjarneo

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 ;)

bytebone avatar Sep 15 '22 16:09 bytebone

Yeah, correct :) And, if you have an MITM attack, then you surely have other issues as well ;)

bjarneo avatar Sep 15 '22 18:09 bjarneo