W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2011

Re: Denial of Service using invalid Content-Length header

From: Willy Tarreau <w@1wt.eu>
Date: Mon, 20 Jun 2011 18:38:13 +0200
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: Jan Starke <jan.starke@outofbed.org>, ietf-http-wg@w3.org
Message-ID: <20110620163813.GA12762@1wt.eu>
On Mon, Jun 20, 2011 at 04:21:55PM +0000, Poul-Henning Kamp wrote:
> In message <BANLkTik1rT_Z69xE7YenpB9GPbbxFmKLfg@mail.gmail.com>, Jan Starke wri
> tes:
> >A possible mitigation would be to require SSL or TLS, [...]
> Economically impossible at the bandwidths many sites run.
> >Another (not very mighty) mitigation could be to provide an
> >intermediate layer between TCP and HTTP to handle meta information.
> This is what FreeBSD's "accept-filters" do.  None of the presently
> implemented filters catch this particular case though.  Not really
> sure it is a feasible way to deal with POST bodies though.
> >I have no idea how to really prevent this kind of attack, maybe
> >someone in this mailing-list knows how...
> There is no way to prevent it, it is a direct consequence of the
> protocols, at best you can mitigate it.
> The best mitigation is to have high-level detection software that
> says "Funny, we've seen a lot of those, lets just summarily
> close all unauthenticated POST attempts until they get bored" and
> similar.
> The second best mitigation is to write your code to spend as few
> resources as possible, until you can commit to the request.

I would add that the *first* protection obviously is to have the
server correctly implement timeouts, because if it is sensible to
this attack, it's also sensible to simple client failure.

Quite honnestly, I see nothing new here, it been abused for at least a
decade by DDoSers and I'm not sure there are not that many servers which
are *that* sensible. In fact, if the slowloris attack was playing on
headers, it precisely is because playing on data us much less effective
with servers, but the principle is the same (ie: maintain a server state
for a long time).

Received on Monday, 20 June 2011 16:38:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:52 UTC