search

dotnet / aspnetcore

ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.
https://asp.net
MIT License
35.19k stars 9.93k forks source link

Add support for X-Azure-FDID as a UseForwardedHeaders "Known Proxy" #47408

Open raramer opened 1 year ago

raramer commented 1 year ago

Is there an existing issue for this?

Is your feature request related to a problem? Please describe the problem.

I am trying to use UseForwardedHeaders in an app behind Azure Front Door, but the remote ip address received on the application is random. The only options I see right now are to either restrict known networks to a class B (147.243.x.x based on observations) or remove all known proxies from the configuration. Basically, drastically reduce security or remove it completely.

Describe the solution you'd like

A great feature would be to configure ForwardedHeadersOptions with an expected header and value as an alternate security mechanism to remote ip address.

Ex. options.KnownHeaders.Add("X-Azure-FDID", "55ce4ed1-4b06-4bf1-b40e-4638452104da");

Additional context

No response

Tratcher commented 1 year ago

That seems like a check that could be added as its own middleware. E.g. if this header/value is missing, refuse the request (400). That would be independent of UseForwardedHeaders, it doesn't modify any part of the request.

raramer commented 1 year ago

That would be case if I wanted to only respond to requests coming through the proxy. In my case, I want the application to also respond to requests that aren't proxied.

Looking at the existing UseForwardedHeaders code, the KnownProxies and KnownNetworks are only restricting whether the host, remote ip address, and protocol are replaced, and don't do anything to block the inbound request itself. KnownHeaders would do the same; only restrict replacements, and not the entire request.

Tratcher commented 1 year ago

Note there is a proposal for UseForwardedHeaders to reject requests that don't match its criteria rather than no-op: https://github.com/dotnet/aspnetcore/issues/10302

Tratcher commented 1 year ago

UseWhen is another option for you, skip the forwarder middleware when the expected header is not present.

Triage: I don't recommend implementing this until we get more feedback about it and possible variations.

ghost commented 1 year ago

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.