Re: HTTPbis -10 drafts published : Connection header

What kind of exploit? Remember that Connection only affects the headers in *this* message; i.e., in your scenario, the client couldn't affect the response headers.



On 15/07/2010, at 10:45 AM, Adrien de Croy wrote:

> 
> that's quite an interesting scenario
> 
> if a proxy were to receive a request message with say
> 
> Connection: content-type
> 
> in it, what do you think should the proxy do?
> 
> a) ignore it (not remove Content-Type)
> b) reject the message (client attempted exploit)
> c) something else
> 
> it may be clear enough for Content-Type, but what about some other header (e.g. header not known about by the proxy).  Should we have a requirement that a proxy should reject any message that has a token in the Connection header that is not a known hop-by-hop header?
> 
> regards
> 
> Adrien
> 
> 
> On 14/07/2010 8:55 p.m., Willy Tarreau wrote:
>> Hi,
>> 
>> On Tue, Jul 13, 2010 at 08:18:10AM +0200, Julian Reschke wrote:
>>   
>>> <http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-10#appendix-D.11>
>>>     
>> Here I have found something that ought to be clarified concerning
>> the Connection header :
>> 
>> 9.1. Connection
>>    HTTP/1.1 proxies MUST parse the Connection header field before a
>>    message is forwarded and, for each connection-token in this field,
>>    remove any header field(s) from the message with the same name as the
>>    connection-token.  Connection options are signaled by the presence of
>>    a connection-token in the Connection header field, not by any
>>    corresponding additional header field(s), since the additional header
>>    field may not be sent if there are no parameters associated with that
>>    connection option.
>> 
>>    Message headers listed in the Connection header MUST NOT include end-
>>    to-end headers, such as Cache-Control.
>> 
>> The last sentence is already very important, but some side effects
>> remain on some implementations, because it is not stated that only
>> headers that were given by the client must be removed. If you take
>> Apache 2.2 as a proxy for instance, by default it will add an
>> "X-Forwarded-For" header when forwarding the connection to the
>> server, to indicate the client's address. If the client says
>> "Connection: X-Forwarded-For", then this header is removed from the
>> output and the server does not get the client's address. I've not
>> checked the code, but I think this is because the header cleaning
>> happen just before forwarding the connection, and after header
>> addition. This can permit a client to alter the semantics of the
>> communication between a proxy and a server, possibly bypassing some
>> filtering or hiding its activities. I think that adding a sentence
>> such as the following would be fine :
>> 
>>    If an HTTP/1.1 proxy intends to modify or add headers to the
>>    message being forwarded, it may only do so after the headers
>>    above have been removed.
>> 
>> I've also tried to remove "Connection" (which is a hop-by-hop header)
>> with Apache and fortunately it did not work. Out of curiosity I tried
>> with "Content-Length" and "Host" and they did not work either.
>> However, when I try to remove "Transfer-Encoding" (hop-by-hop) on a
>> POST with empty body, I observe that "Content-Length: 0" is not added
>> to the request, which is harmless (the request will be rejected due
>> to missing content length).
>> 
>> I've just found that other end-to-end headers such as "cache-control",
>> "content-encoding" etc... can still be removed via Apache, possibly
>> leading to differences in contents interpretation between the proxy
>> and the server (eg: when content filtering is performed), though this
>> is purely implementation-specific. However, implementation-specific
>> differences or limitations sometimes indicate a difficulty in fully
>> understanding or respecting a standard.
>> 
>> Regards,
>> Willy
>> 
>> 
>>   
> 


--
Mark Nottingham     http://www.mnot.net/

Received on Thursday, 15 July 2010 00:51:01 UTC