search

dotnet / AspNetCore.Docs

Documentation for ASP.NET Core
https://docs.microsoft.com/aspnet/core
Creative Commons Attribution 4.0 International
12.64k stars 25.28k forks source link

bearer tokens are sent in an HTTP header. However, SignalR is unable to set #13642

Open kiril-chilingarashvili opened 5 years ago

kiril-chilingarashvili commented 5 years ago

The documentation on this page states the following: In standard web APIs, bearer tokens are sent in an HTTP header. However, SignalR is unable to set these headers in browsers when using some transports. **When using WebSockets and Server-Sent Events, the token is transmitted as a query string parameter.**

As I understand developer does not have control over the code, to disable this dangerous fallback mode of sending auth. token? Leaking the token means giving over full control over the resources owned by token. Or, is the "query string" is meant to be a different mechanism of passing parameters from what I understand as "passing data in a clear text in url of a request"?

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

BrennanConroy commented 5 years ago

Hello @kirill-chilingarashvili thanks for your interest in SignalR.

Query strings and headers are both plain text when using HTTP. However, you should be using HTTPS when auth is involved, and both query strings and headers are encrypted over HTTPS.

Are you seeing the query string as "clear text" somewhere that it shouldn't be?

We do document that the query string may be logged on the server and some steps you can do to avoid that. https://docs.microsoft.com/aspnet/core/signalr/security?view=aspnetcore-2.2#access-token-logging

kiril-chilingarashvili commented 5 years ago

I was referring to fact that having sensitive data in query string in general is less safe than having it in headers (considering we use HTTPS in both cases), again due to possible logging issues

I was looking for and did not find a way of switching off falling back to query string.

Also it is not obvious for non HTTPS protocol - it should be disabled for HTTP IMHO

analogrelay commented 5 years ago

I was looking for and did not find a way of switching off falling back to query string.

The problem here is that SignalR is limited by browser API support. It is not possible to set any headers from the JavaScript WebSocket or Server-Sent Events client APIs. We have some thoughts on how to improve this in future versions, but for now this is the limitation we have. If you disable the WebSockets and Server-Sent Events transports (and use only Long Polling) then we use the Authorization header. Non-Browser clients (NodeJS, .NET, Java, etc.) use the Authorization header for WebSockets and Server-Sent Events as well since they don't have the same limitation browsers do.

(whatwg/websockets#16 is tracking adding support for custom headers to browser APIs but hasn't even been added to the spec yet, so it'll be a while)