Closed Nantero1 closed 3 years ago
This is a change that was contributed many years ago (https://github.com/miguelgrinberg/Flask-HTTPAuth/issues/38 and https://github.com/miguelgrinberg/Flask-HTTPAuth/issues/39). I don't remember much about that bug report, but yeah, seems it would be best for this extension to not read the request, considering the possibility that resources (memory, disk space) have to be used. For any cases where this is a problem, the application and read the request itself at their own risk.
Release 4.5.0 is out with this fix. Thanks!
I hope I'm wrong, but maybe I found a security issue π
Line 166 is problematic: https://github.com/miguelgrinberg/Flask-HTTPAuth/blob/dc6de2dc9e1203e42d2763a0914e16ce96b74035/src/flask_httpauth.py#L164-L166
Even if the user is unauthorized, files send via a form will be processed. In case of large files, even local temp files will be created. This can be used for DoS attacks, by flooding the Flask service with large files, filling the temp drive and/or keeping the service threads occupied until the whole service becomes unresponsive π£ .
Please run this example code, upload a large file and authenticate yourself with a wrong username/password combination. Watch the service process the large file (response takes some time, service is occupied by this task) or even debug and watch the temporary file being created on the disk, despite a wrong authentication was given π’ .
I would suggest, NOT to clear the TCP receive buffer of any pending data, when the authentication is invalid.
For others: My workaround is to use
flask.abort(401)
immediately, after the username and password verification fails in theverify_password
function.