Re: [NEW ISSUE] Content-Length and Transfer-Encoding: security implications

Yutaka Oiwa wrote:
> Adrien de Croy wrote:
>
>   
>> Does this mean there should (if there are no further recommendations
>> made for servers / UAs) at least be some requirements specified for
>> proxies in this case?
>>     
>
> Yes.  The proxy should not forward at least second request to the upstream.
>   
the problem is, to the proxy this second request is simply entity body.  
To the receiving server however it's a pipelined request.

Wouldn't the best approach be to ban Transfer-Encoding from HTTP/1.0 
clients?  Removing the Transfer-Encoding header in this case solves the 
problem, as then the payload of the post is correctly encapsulated.

So maybe the requirement needs to be dependent on the HTTP version 
number.  i.e.

for HTTP/1.0 requests, Content-length takes precedence, and 
Transfer-Encoding should be ignored and removed by proxies
for HTTP/1.1 requests, Transfer-Encoding takes precedence, and 
Content-Length should be ignored and removed by proxies.


>   
>> e.g a proxy must not change the meaning of request headers (in this case
>> Transfer-encoding) by virtue of simply forwarding the request with a
>> different HTTP version tag.
>>     
>
> Maybe yes.  However, such "indirect" specification requires every proxy to
> understand the meaning of request in older versions of protocol, and carefully
> implement the comparison of "the meaning".  Another issue is some kind of
> "forward compatibility" nature of the HTTP: such specification forbid HTTP/1.1
> proxies to understand defacto-standard HTTP/1.0 Host and Connection headers.
> Instead, I prefer to explicitly forbid Content-Length/Transfer-Encoding case.
>
>   

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Tuesday, 4 December 2007 20:07:23 UTC