Issue: WebSocket Token in URI

[Berndinox]

Subject of the issue

I dont want my Token to be sent via URI
After authentication JWT Token is transmitted in HTTP Header as usually. However Bitwarden is also trying to establish an WebSocket Connection for Realtime. For that porpose the following URL is called:
wss://domain.com/notifications/hub?access_token=JWT_TOKEN

That call can easily be logged without breaking the SSL Connection. (Forward-Proxy, Reverse-Proxy, Wireshark)

An Attacker can use that token to get access to the account.
YES, the passwords are still client side encrypted so there is no "super-danger".

However, in my optionion a password-manager should not send long living Token via URI.

See also: https://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html#query-param
"This method is included to document current use; its use is not recommended, due to its security deficiencies (see Section 5) and also because it uses a reserved query parameter name, which is counter to URI namespace best practices, per "Architecture of the World Wide Web, Volume One" [W3C.REC‑webarch‑20041215]."

Temporary Token with short lifetime could fix that issue.

EDIT:
What is strange, that i still log this after setting: WEBSOCKET_ENABLED: "false"

WebSocket connection to 'wss://domain.com/notifications/hub?access_token=TOKEN' failed: Error during WebSocket handshake: Unexpected response code: 403

403 is just because i have not rule for /notification/hub to Websocket Port

[jjlin]

I dont want my Token to be sent via URI
After authentication JWT Token is transmitted in HTTP Header as usually. However Bitwarden is also trying to establish an WebSocket Connection for Realtime. For that porpose the following URL is called:
wss://domain.com/notifications/hub?access_token=JWT_TOKEN

That call can easily be logged without breaking the SSL Connection. (Forward-Proxy, Reverse-Proxy, Wireshark)

This is how upstream Bitwarden works currently, so there's nothing bitwarden_rs can do about it if it wants to remain compatible. I don't know if upstream would consider this to be a feature request, but you could try https://community.bitwarden.com/c/feature-requests/5 or https://github.com/bitwarden/server/issues.

What is strange, that i still log this after setting: WEBSOCKET_ENABLED: "false"

WebSocket connection to 'wss://domain.com/notifications/hub?access_token=TOKEN' failed: Error during WebSocket handshake: Unexpected response code: 403

403 is just because i have not rule for /notification/hub to Websocket Port

This is expected. The web/browser/desktop clients always try to establish a WebSocket connection, regardless of whether the server has it enabled (I'm not sure the upstream server even allows you to disable WebSockets).

[BlackDex]

Upstream doesn't allow to disable it. Actually, the only reason we have that option i think is because there is no native integration with rocket right now.

[Berndinox]

Hej @jjlin @BlackDex : thanks for clarification. I was not sure about where to report. I will get in Touch with the upstream project. Thanks and have a nice day

[mqus]

I'm just an interested stranger, aren't the only things not covered by TLS metadata like the IP and the domain name (SNI)? an URL parameter like ?access_token=JWT_TOKEN should be covered at the very least. and the scenario you're describing (am I understanding this right?) is client -> reverse proxy(temrinating TLS) -> wireshark -> forward proxy(reopening TLS) -> Server, meaning a MITM attack where the MITM reverse proxy is authenticated... this is not a bitwarden issue, but an issue which TLS 1.3 already solves...

just to be sure, I'm just asking about your "without breaking the SSL connection" & "with wireshark", the logging is a valid concern which is (as you noted) also described in the IETF document.

The wireshark issue (if it indeed exists) can not be solved by moving the Token in the HTTP header.

This is then just dangerous in case of accidental logging, but not for MITM attacks.

[Berndinox]

Hej, the term "without breaking the SSL connection" is slightly mispronounced. TLS is indeed protecting URIs.
I stumbled over this when fixing an issue on my reverse-proxy (inrgess-controller) on kubernetes.
The URI is logged, and then collected inside ELK stack, making it trivial to expose the keys of any user.

I also asked on the official bitwarden/web repo if there is any other way to auth websocket. But it seems like there is not other solution, yet.

BR Bernd

[ainola]

Hi all, it looks like upstream has changed that functionality per bitwarden/server#3650