Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Security audit #1

Open
bjarneo opened this issue Jun 13, 2021 · 5 comments
Open

Security audit #1

bjarneo opened this issue Jun 13, 2021 · 5 comments
Labels
help wanted Extra attention is needed

Comments

@bjarneo
Copy link
Member

bjarneo commented Jun 13, 2021

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

@bjarneo bjarneo added the help wanted Extra attention is needed label Jun 13, 2021
@bjarneo
Copy link
Member Author

bjarneo commented Aug 22, 2022

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 cd79333

@bytebone
Copy link
Contributor

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

@bjarneo
Copy link
Member Author

bjarneo commented Sep 14, 2022

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

@bytebone
Copy link
Contributor

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

@bjarneo
Copy link
Member Author

bjarneo commented Sep 15, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants