Re: Dealing with bad server chunking

Hi Adrien,

On Fri, Mar 15, 2013 at 04:44:30AM +0000, Adrien W. de Croy wrote:
> Hi all
> 
> 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.

Regards,
Willy

Received on Friday, 15 March 2013 06:48:51 UTC