SignalR is exposing access_token in query params
AMAhmadMuztaba opened this issue · comments
SignalR is sending access_token in the query parmeter . But in a recent pentest, it is shown as a 'two bomb finding'.
I have gone though "https://learn.microsoft.com/en-us/aspnet/core/signalr/security?view=aspnetcore-7.0" -where Microsoft claims sending though query params is as secure as sending through headers . why is it secure?
is there any way to hide the access token from the network call so that it doesn't get exposed?
Browser does not allow adding headers with WebSocket connections, that’s why the token is in the query string, that is a general practice for JS WebSocket connections.
From a security perspective, it doesn't really matter where the access token is stored. In an ordinary HTTP request it would be stored in the header, or in a message after the WebSocket connection is established. However, many websockets for clients don't support client headers, and both of these are equally accessible to an attacker who can inspect traffic. Connections default to being over TLS these days, so from the outside you can't access query params, nor can you access the contents of messages.
Traditionally it was considered poor practice to have credentials in query params because URLs can get stored in places such as logs for proxies, browser history, etc. However, neither of those concerns apply to websockets (a browser won't keep history of the connections made by a page), and proxies do not have access to the URL when there is a TLS tunnel. This concern arose when non-TLS interactions were the default. For comparison, most OAuth flows result in an endpoint access being made with an access_token query param.
What about HTTP server logs? I got a negative pentest result from passing access tokens in the URI parameter.
A web socket upgrade request is actually a GET request, and it seems to be logged along with an entire URL to server logs, possibly giving server admins impersonation-ready credentials.
I've studied the code of SignalR TS (js) library and the token is always passed in the case of a web browser: https://github.com/dotnet/aspnetcore/blob/ec9a2d83b54ee370a2ae75c632d5f442d09ba482/src/SignalR/clients/ts/signalr/src/WebSocketTransport.ts#L75. I thought the library is somehow compatible with the authentication ticket method, but unfortunately, it explicitly requires access tokens instead of one-time access tickets.
A reference to vulnerability description: https://owasp.org/www-community/vulnerabilities/Information_exposure_through_query_strings_in_url
Up, still no solutions or workaround here ?