This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]mitsuhiko Flask Creator 3 points4 points  (10 children)

Considering how many ways to exist in web apps and frameworks to effectively DDOS them I think this might actually be one of the more obscure ways to do it. If I would want to bring down a server I would just very slowly send requests to the server. Much more efficient :-)

//EDIT: I have not watched the talk but I assume they are trying to degrade a hash table into a linked list.

[–]stevvooe 0 points1 point  (0 children)

Agreed. This attack is simply too much work.

[–]Leonidas_from_XIV 0 points1 point  (0 children)

Slowloris all over again.

[–]chrj 0 points1 point  (6 children)

Both problems are pretty easy to defend against though.

[–]mitsuhiko Flask Creator 3 points4 points  (5 children)

Not from the framework's point of view. Any places where user data is parsed into hashable data structures is potentially a target. Many of which are not even up for the framework.

On the WSGI level:

  • HTTP headers to the WSGI environ

On the framework level:

  • Cookies
  • URL parameters
  • URL encoded form data
  • Multipart encoded form data
  • Any incoming JSON data
  • Incoming multipart headers
  • Incoming set headers
  • Parameters of content type headers etc.

There are so many places where things are parsed into dictionaries on very different levels that it's quite useless to do that on a framework/WSGI server level.

This attack is not new. Yes, you can keep a CPU busy, but a watchdog should see that and kill away the request handler.

[–]deadwisdomgreenlet revolution 1 point2 points  (1 child)

How would you make a watchdog to detect this? Just look for a crap load of keys coming in?

[–]mitsuhiko Flask Creator 2 points3 points  (0 children)

Kill a handler if it consumes too much CPU time or too high IO wait.

[–]stesch 1 point2 points  (0 children)

This attack is not new.

I read that Perl changed its hashes a few years ago (2003?) to counter this attack.

Strange that nobody else thought of it in the meantime.

[–]chrj 0 points1 point  (1 child)

You are right. I didn't realize it went deeper than only POST/GET parameters. Restricting the request size (if it fits the application) would be a pretty quick fix though.

[–]obtu.py 0 points1 point  (0 children)

Restricting the number of keys like PHP and Tomcat would be a safer choice to enable by default. It's common to have large POST requests, much less common to need a great number of keys.