Note that the cookie is not changed every request, just the token retrieved
by the `get_token()` method (used also by the `{% csrf_token %}` tag).
While at it, made token validation strict: Where, before, any length was
accepted and non-ASCII chars were ignored, we now treat anything other than
`[A-Za-z0-9]{64}` as invalid (except for 32-char tokens, which, for
backwards-compatibility, are accepted and replaced by 64-char ones).
Thanks Trac user patrys for reporting, github user adambrenecki
for initial patch, Tim Graham for help, and Curtis Maloney,
Collin Anderson, Florian Apolloner, Markus Holtermann & Jon Dufresne
for reviews.
Added the CSRF_TRUSTED_ORIGINS setting which contains a list of other
domains that are included during the CSRF Referer header verification
for secure (HTTPS) requests.
Only compute the CSRF_COOKIE when it is actually used. This is a
significant speedup for clients not using cookies.
Changed result of the “test_token_node_no_csrf_cookie” test: It gets
a valid CSRF token now which seems like the correct behavior.
Changed auth_tests.test_views.LoginTest.test_login_csrf_rotate to
use get_token() to trigger CSRF cookie inclusion instead of changing
request.META["CSRF_COOKIE_USED"] directly.
Thanks to brodie for the report, and further input from tow21
This is a potentially backwards incompatible change - if you were doing
PUT/DELETE requests and relying on the lack of protection, you will need to
update your code, as noted in the releaste notes.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@16201 bcc190cf-cafb-0310-a4f2-bffc1f526a37
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.
In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.
All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.
There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Thanks to jbg for the report.
This changeset essentially backs out [13698] in favour of a method that
sanitizes the token rather than escaping it.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@13732 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Anton Samarchyan
Claude Paroz
Raphael Michel
Holly Becker
Tim Graham
Shai Berger
Florian Apolloner
Vasiliy Faronov
chemary
Marten Kenbeek
Matt Robenolt
Joshua Kehn
Jay Cox
Grzegorz Slusarek
Roger Hu
Milton Mazzarri
Alex Gaynor
Bouke Haarsma
Aymeric Augustin
Andrew Godwin
Olivier Sels
Collin Anderson
Adrian Holovaty
Paul McMillan
Jannis Leidel
Luke Plant
Russell Keith-Magee