Security implications of using IHttpContextAccessor in Blazor Server

[Bouke]

(I originally posted this question on the Docs repository, but I was told to post it here instead.)

The documentation note the following on IHttpContextAccessor:

Additionally, again for security reasons, you must not use IHttpContextAccessor within Blazor apps. Blazor apps run outside of the context of the ASP.NET Core pipeline. The HttpContext isn't guaranteed to be available within the IHttpContextAccessor, nor is it guaranteed to be holding the context that started the Blazor app.

The default HttpContextAccessor is implemented using AsyncLocal:

https://github.com/dotnet/aspnetcore/blob/589aa11b5c631ce719e0530d66be8324a6d79169/src/Http/Http/src/HttpContextAccessor.cs#LL11C108-L11C108

I fail to understand the security implications of using IHttpContextAccessor in Blazor Server. AsyncLocal in general must flow with the user's SignalR connection†. So that would also be the case for the HttpContext stored in this AsyncLocal. This is also what we're seeing in our tests.

• Under what situations would IHttpContextAccessor return a different HttpContext than the one that started the Blazor app? (i.e. another user)
• How is this use of AsyncLocal any different from other uses of AsyncLocal and (apparently) a security consideration?
• How can we pass the originating HttpContext from the "context of the ASP.NET Core pipeline" safely to the Blazor Server app?

† If that isn't the case, then all bets are off.

cc: @guardrex dotnet/AspNetCore.Docs#27944

[guardrex]

Thanks, @Bouke. I just found the following open issue to work further on this subject in SignalR docs. It wasn't apparent to me at first because it's labeled for the SignalR docs, not the Blazor docs and not tracked by the Blazor project. It might provide some helpful info to you while you wait for a response here ...

dotnet/AspNetCore.Docs#14974

Javier ... when you see this ... let me know if you'd like any additional guidance added to that bit in the Blazor doc. 👂

Also, the issue ☝️ has been languishing since 2019 without an assignee (but it is on Brady's master list of things to do). What I think will happen is that this will get covered in the SignalR docs. I'll cross-link to the new coverage from relevant Blazor-node docs. If that's not the plan, let me know what you'd like to do. 👂

[davidfowl]

I believe the issue is that Blazor server circuits survive across multiple SignalR connections. This is the same reason why you have to get the HttpContext within SignalR using HubConnectionContext.GetHttpContext(). The accessor doesn't work well because SignalR connection can persist across multiple http requests. In the case of Blazor server, the circuit is the source of truth and that can also be handled across multiple http requests and SignalR connections. What you don't want to happen is for the user captured in a service to be the wrong one because the user context changed after a reconnect but your code didn't notice.

The IHttpContextAccessor can be made to "work" somewhat by either:

• Nulling it out so that you see null within these contexts when you access the HttpContext
• Trying to make it work whenever we update a view of the HttpContext in these frameworks. Though its unclear to me where the framework would do this.

[Bouke]

So the security implication being referred to in the documentation would be the following:

• User A starts the Blazor application, and thus their user is captured in HttpContext.User
• From within the Blazor application User A is signed out and User B is signed in (all the while maintaining their SignalR connection)
• Now HttpContext.User still refers to User A?
  Meaning that if my Blazor application doesn't handle sign-ins, is there still a security implication that I need to consider?

So coming back to the circuit being the source of truth, I would still expect AsyncLocal to correctly flow; is this not the case?

What you don't want to happen is for the user captured in a service to be the wrong one because the user context changed after a reconnect but your code didn't notice.

Can you clarify what you mean by this, is this the scenario that I described above?

---

For some background: I have a design where my business layer receives an IUserProvider that has a sole method IPrincipal GetUser(). Depending on the type of application, I would inject in web contexts a HttpContextUserProvider that relies on IHttpContextAccessor, or in non-web contexts a ThreadUserProvider that uses Thread.CurrentPrincipal. The advertised way to get a user in Blazor is with AuthenticationStateProvider, but I cannot plug that into my existing design. I need to register something with the DI that isn't async and works both in MVC and Blazor. In my testing IHttpContextAccessor appears to be working fine, except the very first render following a hot reload, which is how I came to further investigate IHttpContextAccessor's trade-offs.

[davidfowl]

From within the Blazor application User A is signed out and User B is signed in (all the while maintaining their SignalR connection)

Right, this is the same reason why it's unsafe to do use the IHttpContextAccessor in SignalR. The user attached to the Blazor circuit is updated but the IHttpContextAccessor never gets updated again.

Now HttpContext.User still refers to User A?
Meaning that if my Blazor application doesn't handle sign-ins, is there still a security implication that I need to consider?

Right, the async local captured by the initial SignalR connection is what will flow to the blazor circuit and subsequent requests, or connections will not update the async local you captured previously.

PS: I wrote a things that can go bad with async locals article.

In my testing IHttpContextAccessor appears to be working fine, except the very first render following a hot reload, which is how I came to further investigate IHttpContextAccessor's trade-offs.

Try the scenario you listen above. If it's "working", it's definitely by chance and not intended 😄 (which means it's not really working). The HttpContext pointed to by the accessor gets disposed/reset after the request is over. There are many IHttpContextAccesor.HttpContext instances over the lifetime of the circuit, so it's very unsafe in that sense.

I have a design where my business layer receives an IUserProvider that has a sole method IPrincipal GetUser()

To make it safe, it needs to be updated with the "right" instance of the HttpContext at the appropriate time (I haven't spent much time trying to understand what that is). Maybe you can update it in a circuit handler or in a hub filter.

BTW if you just need the user an not the HttpContext, its cleaner to set Thread.CurrentPrincipal in all the right places.

[guardrex]

I'm going to expand what we have in the Blazor Threat Mitigation doc and probably add a bit on this in the Blazor-SignalR Fundamentals doc.

There's a bit on this in the HttpContext doc. The best content to cross-link will be whatever is placed for dotnet/AspNetCore.Docs#14974. I'll cross-link to whatever they place.

[javiercn]

All that @davidfowl mentions here is correct.

I have a design where my business layer receives an IUserProvider that has a sole method IPrincipal GetUser()

Use a CircuitHandler capture the User there from the AuthenticationStateProvider and set that user in your service. If you want to get updates to the user, register a callback to AuthenticationStateChanged and queue a Task to get the new user and update your service.

Hi @Bouke. We have added the "Needs: Author Feedback" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[davidfowl]

@javiercn I think we should write a full example.

[javiercn]

@davidfowl do you mean for what I suggested?

[davidfowl]

yep