Fixed #20869 -- made CSRF tokens change every request by salt-encrypting them

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.
This commit is contained in:
Shai Berger 2015-11-07 18:35:45 +02:00
parent 6d9c5d46e6
commit 5112e65ef2
8 changed files with 241 additions and 70 deletions

View file

@ -65,10 +65,10 @@ this if you know what you are doing. There are other :ref:`limitations
<csrf-limitations>` if your site has subdomains that are outside of your
control.
:ref:`CSRF protection works <how-csrf-works>` by checking for a nonce in each
:ref:`CSRF protection works <how-csrf-works>` by checking for a secret in each
POST request. This ensures that a malicious user cannot simply "replay" a form
POST to your website and have another logged in user unwittingly submit that
form. The malicious user would have to know the nonce, which is user specific
form. The malicious user would have to know the secret, which is user specific
(using a cookie).
When deployed with :ref:`HTTPS <security-recommendation-ssl>`,