Subject: p1-messaging: request line trailing SP

From: Amos Jeffries <[email-masked]>
Date: Sat, 06 Oct 2012 01:14:31 +1300

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 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).

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

---

From: Zhong Yu <[email-masked]>
Date: Fri, 5 Oct 2012 11:28:28 -0500

On Fri, Oct 5, 2012 at 7:14 AM, Amos Jeffries <[email-masked]> wrote:
> 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?

> 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
>