Re: [RFC] drop Request-Range header support

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.
Received on Thu Feb 27 2014 - 05:21:23 MST