Cookies stored in local storage
janmasarik opened this issue · 5 comments
Token is stored in local storage which isn't recommended etc by OWASP. Due to the nature of vault, this token should be secured as much as possible.
Was this design decision? If so, why did you prefer local storage over cookies with secure flags (strict SameSite + Secure + HTTPOnly )?
Otherwise, I just wanted to say thanks for nice UI 👍.
The feature you are likely looking for is here: https://github.com/Caiyeon/goldfish/wiki/Configuration#transit-encryption-optional
Details on how this feature works:
Wall of text explaining the design choice behind localstorage and cookie-less:
The alternatives are sessionstorage and secure cookies. Session storage is not officially supported in multiple tabs, so that's out.
Goldfish used secure cookies before (iirc v0.4.x?) but there were many problems. One of goldfish's design principles is that the server should not remember any part of a user's transaction after the request is complete. This means that goldfish cannot issue session identification, as that requires goldfish to store the user's token in memory.
There is a way to circumvent this, by encrypting the user's credentials with asymmetric encryption. This way, goldfish does not remember the user's credentials, and the user's credentials are kept safe as a cookie. For this reason, goldfish used to use gorilla securecookies package. However, it required every restart to initialize a different key. This meant that when goldfish is restarted, every user's cookie is unrecognizable, and the only error they will receive is "invalid authentication", forcing them to relogin.
In addition, cookies are notoriously difficult to implement securely. CSRF protection needs to be used everywhere. Many popular platforms built by people much smarter than me were vulnerable to CSRF (see: youtube, twitter, etc.). I had to tiptoe too much for this to be a solid choice.
Thanks for quick response and explanation.
However, I don't agree that CSRF tokens are really that hard to implement in smaller applications like goldfish 🤷♀️.
Perhaps not, but it is much easier to let vault do the encryption, especially since it allows for features like key rolling :)
But that doesn't protect you against XSS of any kind. Once the attacker gets encrypted token without notice of maintainer, he can use it to send requests to goldfish UI as long as the ServerTransitKey won't be changed.
The key does not have to be changed, it can be rolled via vault's PKI API. This takes the "break glass in case of emergency" button into the hands of the operator, who does not even need goldfish to roll this key.
XSS is another problem in and of itself. Having HttpOnly flag does not 100% prevent cookie stealing - at least, last I checked. Having a secure cookie implementation still necessitates XSS prevention anyway. It's not like a cookie would be better in the case of an XSS exploit.
If the security model of goldfish is not adequate, I would highly recommend supporting HashiCorp by using their recently open sourced UI. If their UI was open source to begin with, perhaps goldfish would have never been necessary :)