On 27/02/2014 6:21 p.m., Alex Rousskov wrote: > 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?
(A) can be hard-coded in the form of either: i) dropping it from the header registry + using delByName() on every request, OR ii) dropping explicit mentions of it outside the header registry, setting its field type to generic String, and adding it to the connection-headers mask. (B) the putRange() can detect multiples and set the range to a special (empty header?) value that gets stripped at the end of parsing. In order not to reject even counts of Range headers while allowing odd-counts. I kind of favour (A), but we may end up having to do both eventually anyway to enforce correct Range compliance. Amos