- From: Zhong Yu <zhong.j.yu@gmail.com>
- Date: Mon, 6 Aug 2012 12:03:41 -0500
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org
Equivalency between URIs is ultimately decided by the application. For example majority of apps ignore unknown query parameters, therefore the attacker can simply append some garbage to expand the key space. The cache needs some other anti-abuse detection mechanism; trying to normalize maliciously crafted URIs won't go very far. Imagine URI was defined to be just an opaque sequence of allowed chars; there's no standard delimiters and escaping rules, it's all up to apps. Would that have caused any serious problems? Probably not. Now URI does define standard delimiters, and the escaping rules that's then necessary, so we can somewhat recognize components of a URI. That's good for anyone who finds it useful. But it's only one flat level. If an app needs deeper structure in URIs, it'll invent its own delimiting and escaping mechanisms. Zhong Yu On Sun, Aug 5, 2012 at 7:31 AM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > In message <501E5A69.5000802@treenet.co.nz>, Amos Jeffries writes: > >>Only if you try to cache along the assumed filesystem hierarchy implicit >>in URLs. Using the absolute URL as an opaque hash key (as Squid does) >>instead of reading any meaning in its syntax avoids all these issues >>completely. > > But opens you up to DoS attacks along the lines of: > > GET /ABCDEF.html > GET /%41BCDEF.html > GET /A%42CDEF.html > ... > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. >
Received on Monday, 6 August 2012 17:04:11 UTC