W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2009

Re: p1-message-07 S 7.1.4

From: Jamie Lokier <jamie@shareable.org>
Date: Sat, 25 Jul 2009 00:24:11 +0100
To: Henrik Nordstrom <henrik@henriknordstrom.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20090724232411.GN27755@shareable.org>
Henrik Nordstrom wrote:
> fre 2009-07-24 klockan 16:35 +0100 skrev Jamie Lokier:
> 
> > Can you describe these problems?  I've not heard of any problem with
> > chunked response encoding, and it's very widely deployed.
> 
> Basically it makes the response splitting attack much easier, removing
> any need of guessing response sizes and also completely defeats any
> Content-Length the server manages to add before of the injected header
> payload unless the receiver ignores specifications and verifies
> Content-Length instead of ignoring it.
> 
> But as I said the damage is primarily isolated to the requested site,
> and additionally the server of that site needs to be broken to exploit
> it.
> 
> But me sitting on the proxy chair have a little harder time as I also
> need to deal with certain "forgiving" proxies who sends shit back on me
> when the server response is shit.. (not properly verifying message
> boundaries wben there is excess data after the chunked encoding, or
> mistakenly uses Content-Length for delimiting even when there is chunked
> encoding), and in that situation the attack vector becomes serious.

I guess you are saying:

   1. There are real proxies which use Content-Length when they shouldn't.

   2. There are real servers which send Content-Length and chunking
      in the same response.

   3. There are real servers which produce the wrong chunk formatting?

      Do you have specific examples of wrong chunk formatting?
      Are there some well known (in implementer circles) things
      that a robust client must be prepared to accept?

-- Jamie
Received on Friday, 24 July 2009 23:24:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:08 GMT