mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2026-02-05 00:29:40 +03:00
Warm users about access key leakage in access logs #1931
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @rwjack on GitHub (Jun 7, 2024).
Not really a bug, but I think the docs should provide info about this: https://github.com/bitwarden/clients/issues/4290
I just saw that from v1.29.0, WSS is enabled by default, which means all access tokens and encrypted data is being stored in plaintext in reverse proxy access logs, unless the proxy is configured to filter out such requests.
@BlackDex commented on GitHub (Jun 8, 2024):
Which documentation are you referring to? If it is the wiki, then go ahead and add this warning 😄.
Also, i do hope that your reverse proxy can't decrypt the encrypted data and stores that unencrypted somewhere. Not sure what you mean with that specific part. All data is encrypted by the clients and send encrypted over the wire. Those values are never added as GET parameters and thus should not end up in your logs.
@rwjack commented on GitHub (Jun 9, 2024):
I cannot confirm what data is being sent, but something is definitely being sent as a GET request, so some parameters get saved in the access logs.
Here's an example:
@BlackDex commented on GitHub (Jun 9, 2024):
As mentioned, that is only the JWT for the websocket connection indeed. But no other data is ever send via that way, thus no other data, encrypted or unencrypted is ever send over the wire as a GET request.
Only uuid's and are send as part the the path, and maybe timestamps, but that is about it.
Unfortunately there is no other way for the websockets, as the clients do not seem to support any other way then via get parameters.
Also, if some has access to your JWT, that doesn't make them able to decrypt your passwords. So, there isn't any real risk here.
And, the person who has access to those logs can then probably also make adjustments to your reverse proxy and manipulate the web-vault in such a way that it might leak your password, so that would be more of a risk then leaking the JWT I think.
@BlackDex commented on GitHub (Jun 9, 2024):
Also, as this is more of a documentation item and not an issue with Vaultwarden on the server side, ill move this to a discussion.