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

Re: FYI... Binary Optimized Header Encoding for SPDY

From: Zhong Yu <zhong.j.yu@gmail.com>
Date: Mon, 6 Aug 2012 12:03:41 -0500
Message-ID: <CACuKZqGG2Q6=faA+s7QWQzba9D8vSgEmV7rTX7=Pr=UMN4eLxA@mail.gmail.com>
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
> 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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:06 UTC