On 02/26/2014 09:51 PM, Amos Jeffries wrote: > While checking the code against HTTPbis Range draft I think we have a > possible smuggling avenue being enabled by Squid in the form of the > Request-Range header. > > What I can see there in Squid is parsing Request-Range into the same > memory structures as Range. Each time teh header is encountered erasign > prior headers data. Then forwarding the results upstream under the name > Range. > > Only one range header is specified. Multiple is udnefined behaviour. So > the following request may be interpreted differently by other > participants seeing: > > GET / HTTP/1.1 > Range: bytes=0-1000 > Request-Range: bytes=257-1000 > > > * Squid will effectively strip the Range: header and relay the > Request-Range value in Range: upstream. > > * agents closer to the client may be interpreting that as only Range: > header plus unknown header. > > Content-Range on the reply should be sorting out what is actually > delivered so no problems are visible. But any protection based on the > request could be confused or tricked into not processing the reply if it > was only checking based on the RFC standard Range header. > > > This type of crafted request will also have the same behaviour in Squid: > > GET / HTTP/1.1 > Range: bytes=0-1000 > Range: bytes=257-1000 > > > The proposal(s): > > A) treating the Request-Range header as obsolete and erasing it without > processing? > > The only mentions I can find online are CVE-2011-3192 about a > Flash+Apache vulnerability meaning the header had to be blocked from > sending by Flash and XHR mechanisms plus documentation relating. And > that its a legacy header from the days of MSIE 3.0 and Nescape. > So it looks like a candidate for dropping some more code. > > > B) treating multiple Range headers as an error and dropping them all.
Unless they are the same perhaps? I am worried about existing HTTP clients (unknown to me) sending double Ranges (for no good reason). There is no compelling reason to drop all Ranges if they are identical, I think. We can leave and honor one of them. > This would result in Request-Range being treasted somewhat like > Proxy-Connection has been for some time. Either upgraded when its alone, > or dropped if there is a collision. > > > FWIW: the specification says any proxy MAY drop Range at its choice. So > we are permitted to erase this traffic brokenness in either of the above > ways. Do you propose to hard-code actions (a) and (b)? Will some existing or new option control this behavior? Thank you, Alex.
