Re: Dealing with bad server chunking

On Fri, 15 Mar 2013, Willy Tarreau wrote:

> On Fri, Mar 15, 2013 at 04:44:30AM +0000, Adrien W. de Croy wrote:
> > 
> > we have recently had issues with a site where the server sends chunked 
> > responses back but closes the TCP connection prior to sending any 0 
> > chunk (in fact we never see a packet with this).
> > 
> > WinGate detects this as an abortive close, and if there were any filters 
> > processing the stream, they are reset, and the data may not go to the 
> > client.
> > 
> > However, client browsers typically "forgive" this transgression without 
> > any sort of warning.  Should we be making more forceful suggestions 
> > about this in the specs?
> > 
> > It seems slightly dangerous that a browser would consider content 
> > perfectly fine to use when the chunked transfer was aborted.
> > 
> > Is this actually a security issue, or should we be more tolerant?
> 
> I don't think this is a security issues, however this voids some of the
> benefits of content-length or transfert-encoding, as the client has no
> way to know if the object is complete. A cache should never cache such
> a thing. For the reasons you explained above, in haproxy, when we compress
> a chunk-encoded message, if the message is truncated, we also truncated it
> on output so that the client can decide what to do with it and knows we
> didn't get it full (eg: a cache can decide not to store it).
> 
> I have seen at least one well-known security gateway try to "fix" incorrectly
> chunked messages, by skipping unaligned chunks etc... *this* is a security
> issue in my opinion, as it allows messages to be accidentely merged. But I
> don't think that accepting a message without 0 CRLF CRLF is a big deal.

I would think it a good idea to distinguish an incomplete last chunk and
missing 0 CRLF CRLF following a completed chunk.

Received on Friday, 15 March 2013 07:32:30 UTC