Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Slowloris DoS Vulnerability #1266
Comments
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
davidism
Dec 4, 2014
Owner
Don't use the development server in production. Use a real application server (uwsgi, gunicorn, etc.) and web server (nginx, apache, etc.).
In fact, the thread you linked goes on to strongly say exactly that.
Don't use the development server in production. Use a real application server (uwsgi, gunicorn, etc.) and web server (nginx, apache, etc.). In fact, the thread you linked goes on to strongly say exactly that. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
LeoTindall
Dec 4, 2014
Contributor
I've seen it in use several times in production. I agree completely that people shouldn't, but they do, so it's still a problem.
I've seen it in use several times in production. I agree completely that people shouldn't, but they do, so it's still a problem. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
davidism
Dec 4, 2014
Owner
I don't speak for the devs, but I doubt you're going to get anywhere on this one with that sort of argument. The answer is that the problem is solved by not using the dev server in production.
I don't speak for the devs, but I doubt you're going to get anywhere on this one with that sort of argument. The answer is that the problem is solved by not using the dev server in production. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
LeoTindall
Dec 4, 2014
Contributor
Fair enough. I'm just pointing out what I found, if/when I get around to fixing it I'll submit a pull request.
Fair enough. I'm just pointing out what I found, if/when I get around to fixing it I'll submit a pull request. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
robertlagrant
commented
Dec 4, 2014
Also look at Waitress. Big fan. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
untitaker
Dec 4, 2014
Owner
Flask's server can handle only one request at a time (unless multithreading or multiprocessing is enabled), so no attacks are necessary in multi-user usage to get it down to its knees. Maybe you could try it with those options enabled, but even then I don't really see it as a problem.
Flask's server can handle only one request at a time (unless multithreading or multiprocessing is enabled), so no attacks are necessary in multi-user usage to get it down to its knees. Maybe you could try it with those options enabled, but even then I don't really see it as a problem. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
LeoTindall
Dec 4, 2014
Contributor
The attack remains effective on the multithreaded version, though it does take longer to work. I would suggest making it more explicit in the documentation that a) the server is vulnerable and b) that it shouldn't be used in production.
The attack remains effective on the multithreaded version, though it does take longer to work. I would suggest making it more explicit in the documentation that a) the server is vulnerable and b) that it shouldn't be used in production. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
Yes, see mitsuhiko#1170 for that. |
LeoTindall commentedDec 4, 2014
The Flask development is vulnerable to RSnake's SlowLoris single-machine denial of service attack. I tested Flask on Ubuntu 14.04 with a Raspberry Pi Model B running Raspbian as the attacker. The DoS succeeded in under a second. This is generally caused by restrictive threading limits, see http://ha.ckers.org/slowloris/
Unfortunately, unlike many webservers, Flask does not seem to recover gracefully when the attack ends, instead throwing broken pipe errors and no longer serving pages until restarted. This affects both debug and normal modes.
Edit: Looks like this was discovered previously and is mentioned here: http://librelist.com/browser//flask/2014/9/2/fwd-dos-via-socketserver/