Duplicated Strict-Transport-Security response header

[davidni]

Describe the bug

We return a duplicated Strict-Transport-Security response header when using the HSTS middleware (UseHsts) and the destination also includes a Strict-Transport-Security response header.

Producing this duplicated response header can be problematic, though it is generally benign (see: Is it fine to use duplicate response header with same value?)

To Reproduce

Proxy setup (pseudo-code):

app.UseHsts();
app.UseRouting();
app.UseEndpoints(endpoints => endpoints.MapReverseProxy());

Destination setup:

• Returns a Strict-Transport-Security response header.

Suggested fix

Do not return a duplicated Strict-Transport-Security value. Perhaps YARP should IGNORE the destination's response header when HSTS is already applied to the current response -- since the YARP-based server already owns TLS termination, it seems reasonable that it should also own the HSTS response.

Further technical details

Repro's with:

• .NET 6.0.8
• YARP 1.1.1

[Tratcher]

We should probably not be proxying Strict-Transport-Security at all, since that's a transport/connection level concern. The front end's HSTS header should be authoritative here.

HSTS would also be strange if the front end was using HTTP and the backend was using HTTPS.

Filtering would be accomplished by adding the header to this list:
https://github.com/microsoft/reverse-proxy/blob/5a86eb4f18474bbe2f9e73f8457f4cbf13c00b81/src/ReverseProxy/Forwarder/RequestUtilities.cs#L58-L82

[samsp-msft]

There may be a bigger problem here. We probably shouldn't ever be receiving a Strict-Transport-Security header from the destination as that would imply that we are communicating with the server using http when it needs https. The correct protocol should be being specified in the destination address.
There could be a corner case where you proxy for a subset of the url space that doesn't need to be secured via http, and the rest via https, but that seems unlikely.
We should definitely be filtering out the Strict-Transport-Security header, and probably warning if we do see it.

Edit: Also how did we miss this header from our review list?

[davidni]

@samsp-msft I think you have that slightly backwards. It is perfectly valid for an https server, accessed over https, to return the Strict-Transport-Security header. This is in fact the only scenario where the response header means anything.

See RFC 6797 section 8.1:

If an HTTP response is received over insecure transport, the UA
MUST ignore any present STS header field(s).

Quoting from your response

We should definitely be filtering out the Strict-Transport-Security header,

Agreed.

(...) and probably warning if we do see it.

I don't think so. Seeing it would be fine if it comes from an https destination that really intends to only ever be called over https. This is the standard case for us.

[samsp-msft]

I was basing my response on https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security where its being used to redirect the browser from the insecure to TLS version of the site.

[Tratcher]

Note: The Strict-Transport-Security header is ignored by the browser when your site has only been accessed using HTTP. Once your site is accessed over HTTPS with no certificate errors, the browser knows your site is HTTPS capable and will honor the Strict-Transport-Security header. Browsers do this as attackers may intercept HTTP connections to the site and inject or remove the header.

HSTS prevents downgrades from HTTPS to HTTP, but you need to use HTTPS first.

[karelz]

Triage: We should block the response header and not forward it in general. That will solve also the problem of duplicates.