Opened 13 years ago
Closed 13 years ago
#16827 closed Bug (fixed)
validate CSRF token (Check length)
Reported by: | jedie | Owned by: | Raúl Cumplido |
---|---|---|---|
Component: | CSRF | Version: | 1.3 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Ready for checkin | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | yes | Patch needs improvement: | no |
Easy pickings: | yes | UI/UX: | no |
Description
I wonder that the CSRF token send from the client didn't be validated.
Don't know if a DOS attack is possible by sending many request with very long CSRF tokens?
IMHO it's a good idea to check the length before do anything with it.
See also: https://groups.google.com/group/django-developers/browse_thread/thread/9fc008d2a3735bc2
Attachments (2)
Change History (8)
comment:1 by , 13 years ago
comment:2 by , 13 years ago
Component: | Uncategorized → contrib.csrf |
---|---|
Needs tests: | set |
Triage Stage: | Unreviewed → Accepted |
comment:3 by , 13 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
I will provide the tests to the pull request.
comment:6 by , 13 years ago
from the source code i noticed that the method
django.utils.crypto.constant_time_compare
is being used for comparing the request token from the one already present in the cookie, since the comparison is already constant time is the length checking really required ?
comment:7 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
aashu_dwivedi: The length check is worth fixing. It is true that the constant_time_compare will fail early if the lengths do not match, but the performance concern is in the regex applied to sanitize the string before it gets to constant_time_compare.
In [17500]:
Patch is here: https://github.com/django/django/pull/45