Aspnetcore.docs: Add warning about how exposing ConnectionId leads to easy impersonation

[halter73]

Related: https://github.com/aspnet/AspNetCore/issues/8681

Issue description

As we make the SignalR clients' ConnectionIds more accessible, we should make it very clear that ConnectionIds should be kept secret as they allow for easy impersonation.

[Rick-Anderson]

@tdykstra can you do this given it's P0 security? cc @bradygaster

[Rick-Anderson]

@tdykstra perhaps implement as an include so you can add it everywhere ConnectionId is used.

[tdykstra]

@mikaelm12

From #11697

We're making changes across the SignalR clients to expose the client connectionId

When will this happen -- is this a 3.0 change?

[mikaelm12]

Yes, this is a 3.0 change.

[Rick-Anderson]

@wadepickett can you do this next? It's P0

[halter73]

Exposing a ConnectionId only leads to easy impersonation if either the SignalR server _or_ the client with the ConnectionId is pre-3.0. If you have a 3.0 server and client, only the ConnectionToken (which isn't exposed via any APIs) and not the ConnectionId needs to be kept secret.

However, since it can be hard to ensure that older clients aren't connecting to the server, I think it's still best to have blanket guidance against exposing ConnectionIds. Do you agree @anurse @BrennanConroy?

[wadepickett]

@anurse and @BrennanConroy, good to go with the guidance Stephan asked about directly above?

@bradygaster
What SignalR topics should we apply the warning to?

• Looking through the SignalR docs I am not finding an explicit example where we suggest exposing a connectionID with a Hub method to return it. I suspect the only place that occurred may have been in stackoverflow discussions.
• So then I looked for examples where we call the new API that exposes the ConnectionID, which I assume to be getCallerConnectionID(). I could not find that API mentioned at all anywhere in the current SignalR docs, however. Maybe we haven’t documented it yet, but once we do, we need to put a warning for any examples?

My apologies to getting to this just now. This issue was assigned to me just as I went on vacation for most of December and the first week of Jan.

[BrennanConroy]

@anurse and @BrennanConroy, good to go with the guidance Stephan asked about directly above?

Yes.

Two places we might want to add a warning are:
https://docs.microsoft.com/aspnet/core/signalr/hubs?view=aspnetcore-3.1#the-context-object where we point out the ConnectionId property
https://docs.microsoft.com/aspnet/core/signalr/security?view=aspnetcore-3.1 add a new topic that talks about ConnectionId?

[wadepickett]

@BrennanConroy, Thanks! I see we could add a new section located right under the WebSockets section of the security doc, and will hit the ConnectionID property in the the Context Object topic.

(+ @halter73 )

In addition to warning to not expose the connectionID on the HUB, and a recommendation of updating to 3.0 for client and server, what other best practice should we recommend? For example, if updating to 3.0 isn't an immediate option, is there any other recommendation?

Could you or someone provide a rough draft of what you would like covered that I could work off of?

Many thanks for the info!

[bradygaster]

Concurred with @BrennanConroy. Thanks immensely for taking this on, @wadepickett.