Updated Dashboard to accept/map forwarded headers

[danespinosa]

Description

This change addresses the need to map the forwarded headers in the application when ASPNETCORE_FORWARDEDHEADERS_ENABLED is enabled. Currently even if a developer enables the ASPNETCORE_FORWARDEDHEADERS_ENABLED environment variable, the application does not map the forwarded headers properly because the application doesn't specify which headers to map.

Without this change the dashboard doesn't work well behind a reverse proxy like YARP when doing OpenID Auth since the app doesn't map the Host or Protocol (http/https) properly and the redirect ends up being the address YARP redirects the call to.

I need guidance for the test I was thinking calling the dashboard and do something similar to ValidateTokenMiddlewareTests to validate the Host, and Proto.

Fixes # (issue)

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
      • No
  • No
• Does the change make any security assumptions or guarantees?
  • Yes, it assumes the developer knows that forwarding headers and mapping them is required for the dashboard to work properly when behind a reverse proxy like YARP. This in certain scenarios could pose a security risk, although it's documented that this dashboard shouldn't be used in production environments.
    • If yes, have you done a threat model and had a security review?
      • Yes
      • No
  • No
• Does the change require an update in our Aspire docs?
  • Yes
    • Is this introducing a breaking change?
      • Yes
        • Link to aspire-docs issue (please use this breaking-change template):
      • No, if this change is accepted it would be good to clarify that the only 2 forwarded headers allowed are the Host and Protocol in here Configuration
        • Link to aspire-docs issue (please use this doc-idea template):
  • No

Microsoft Reviewers: Open in CodeFlow

[adamint]

@JamesNK @drewnoakes
I'm not sure whether there are any security implications here.

[davidfowl]

I’m that doesn’t seem right. Do you need to forward all headers?

[danespinosa]

I’m that doesn’t seem right. Do you need to forward all headers?

@davidfowl I just need XForwardedHost/X-Forwarded-Host that maps to host, that unblocks me to use Microsoft as an Identity provider, I wouldn't know if we need any other headers for other OpenId identity provider though, the other option would be to expose the ForwardedHeaderOptions via the config and let the users decide what headers to forward?

For example if a developer uses Yarp to cut the SSL connection at the edge they will need to map the Protocol too.

[danespinosa]

I’m that doesn’t seem right. Do you need to forward all headers?

@adamint @davidfowl i have limited the forwarded headers to host and protocol, let me know your thoughts.

[adamint]

X-Forwarded-Host

I'm still unsure about the security implications of this change. Someone with a better understanding (maybe @drewnoakes @davidfowl) needs to weigh in, but this approach still seems insecure to me at first glance. Why should we implicitly be trusting X-Forwarded-Host?

Would it change anything to compare the host against an 'expected' host regex? From my perspective, using an identity provider should be a supported but also secure-by-default scenario.

[danespinosa]

Your concerns are valid @adamint, that's why the forwarded headers shouldn't be enabled by default, and should be enabled only by a person that knows how they work with a reverse proxy and why they are needed for their specific scenario, from that perspective this feature is secure by default. In my opinion is that if someone uses this feature, they have some common and basic knowledge like: https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/proxy-load-balancer?view=aspnetcore-9.0 and https://learn.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel/host-filtering?view=aspnetcore-9.0 .

Like any other feature of .NET or Aspire, this can be used by any bad actor, disabling it by default is a must but for advanced or specific scenarios allowing users to leverage it allows application developers to focus on their business logic while leveraging Aspire's great focus on telemetry. From my perspective and security-wise this feature is no different than allowing an unsecure transport (http) for the dashboard, which is currently supported, but discouraged, and should be used at the users' discretion.

[danespinosa]

@adamint answering your comment Would it change anything to compare the host against an 'expected' host regex? From my perspective, using an identity provider should be a supported but also secure-by-default scenario.

Currently I am achieving this by only allowing only the hosts that I am expecting my reverse proxy to call e.g. 10.0.0.1 i do this by setting the AllowedHosts setting in the appSettings.json to the ip 10.0.0.1

[adamint]

Ok thanks for the responses, @danespinosa - and pardon my ignorance. I'm satisfied with this then, @davidfowl?