Forwarded Headers Middleware: Ignore XForwardedHeaders from Unknown Proxy

• You've read the Contributor Guide and Code of Conduct.
• You've included unit or integration tests for your change, where applicable.
• You've included inline docs for your change, where applicable.
• There's an open issue for the PR that you are making. If you'd like to propose a new feature or change, please open an issue to discuss the change or find an existing issue.

Fixes a bug where, under some conditions, XForwardedPrefix , XForwardedProto and XForwardedHost headers could be tampered with.

Description

This PR makes sure that XForwarded-Headers are only interpreted when they come from a known proxy. As suggested by the documentation..

If the ForwardedHeaders.XForwardedFor flag in ForwardedHeadersOptions isn't set. The ForwardedHeadersMiddleware doesn't check if the request comes from a known proxy.

This means that with the following ForwardedHeadersOptions (or any other combination where ForwardedHeaders.XForwardedFor is missing):

var options = new ForwardedHeadersOptions { ForwardedHeaders = ForwardedHeaders.XForwardedHost | ForwardedHeaders.XForwardedProto | ForwardedHeaders.XForwardedPrefix };
_application.UseForwardedHeaders(options);

the respective X-Forwarded-headers will be always processed by the middleware which have some (security related?) side effects:

• XForwardedPrefix sets context.Request.PathBase
• XForwardedProto sets context.Request.Scheme
• XForwardedHost sets context.Request.Host

With ForwardedHeadersOptions set to ForwardedHeaders.All no side effects would have been executed.

Fixes #61449

This observation has been reported by me via the MSRC-Portal but was classified as a product bug. The following information may be related: aspnet/Announcements#295