- From: Zhong Yu <zhong.j.yu@gmail.com>
- Date: Fri, 5 Oct 2012 11:28:28 -0500
- 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 UTC