RE: HTTP/1.1 proxy behavior when Host differs from absoluteURI

On 2014-03-12 06:33, Richard Wheeldon (rwheeldo) wrote:
> I think it's ambiguous. Squid will change the host to match that found
> in the URI. Our CWS proxy will simply disallow and reject the request.
> This is not compliant but no-one has ever complained and I don't think
> I see any legitimate use case for allowing this. It also smells like
> there could be a vulnerability to exploit in certain circumstances.
> Don't expect it to work well in practice.
> 

Cache Poisoning. The security all the way to the server is predicated on 
the URL. Then the final proxy in the chain always faces the choice when 
mapping to partial-URL between retaining the Host header (poisoning the 
client response) and replacing the Host header with the value from 
absolute-URI.

It could also punt and send the absolute-URI and host header to the 
server But under section 5.1 that is the same as replacing it whenever 
the server is compliant.

While undefined there only seems to be one safe choice: replace the Host 
header.

FTR: Squid seems to have been doing its replacement since the beginning 
of HTTP/1.1 without trouble.

Amos

> Regards,
> 
> Richard
> 
> From: Daniel Sommermann [mailto:dcsommer@fb.com]
> Sent: 11 March 2014 16:35
> To: HTTP Working Group
> Subject: HTTP/1.1 proxy behavior when Host differs from absoluteURI
> 
> What is the correct behavior for a (forward) proxy that receives a
> request with an absoluteURI that differs from the Host header? 5.1.2
> suggests that the Host header should be ignored ("Note that the proxy
> MAY forward the request on to another proxy or directly to the server
> specified by the absoluteURI"). 5.2 seems to suggest the same, but
> this section is scoped to the behavior of the origin server, not for a
> proxy.
> 
> If the Host header should be ignored for forwarding by the proxy,
> should the Host header be stripped or forwarded to the next hop?

Received on Tuesday, 11 March 2014 21:50:50 UTC