Issue: WebSocket Token in URI #1423

Closed
opened 2025-10-09 17:14:50 +03:00 by OVERLORD · 2 comments
Owner

Originally created by @Berndinox on GitHub.

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

Originally created by @Berndinox on GitHub. ### 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_
OVERLORD added the troubleshootingenhancement labels 2025-10-09 17:14:50 +03:00
Author
Owner

@jjlin commented on GitHub:

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

@jjlin commented on GitHub: > 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).
Author
Owner

@BlackDex commented on GitHub:

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.

@BlackDex commented on GitHub: 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.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/vaultwarden#1423