W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2012

Re: p1-messaging: request line trailing SP

From: Zhong Yu <zhong.j.yu@gmail.com>
Date: Fri, 5 Oct 2012 11:28:28 -0500
Message-ID: <CACuKZqGdu8isMNJriXLM6D5ALGJs6o_2r0aaDbsYSvB1C9foQQ@mail.gmail.com>
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On Fri, Oct 5, 2012 at 7:14 AM, Amos Jeffries <squid3@treenet.co.nz> wrote:
> I've recently had to explain why Squid does not accept trailing SP
> characters after the HTTP-version part of HTTP/1.1 request lines. It seems
> the security considerations are missing a reference to the potential
> nefarious requests it would enable.
>
> The case in question being a lenient parser which splits the request-line on
> SP assuming that the URL contained no SP characters un-encoded. Such a

The assumption is a valid one, it shouldn't cause any problems.

> parser would be vulnerable to malicious clients sending a URL with embeded
> \0x20HTTP/1.0\0x20 followed by one smuggled header (Host being the most
> deadly).

I don't see how, can you expand on this?

>
> Implementations which instead work forward to the CRLF delimiter then
> backwards to the previous SP delimiter (or somethign to that effect) are
> tolerant of the broken servers and clients which fail to encode SP
> characters within sent URLs without being vulnerable to this problem case.
> At expense that they cannot accept request-line terminated with SP after the
> HTTP-version field.
>
> AYJ
>
Received on Friday, 5 October 2012 16:28:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 5 October 2012 16:28:56 GMT