From 5112e65ef2df1dbb95ff83026b6a962fb2688661 Mon Sep 17 00:00:00 2001 From: Shai Berger Date: Sat, 7 Nov 2015 18:35:45 +0200 Subject: 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. --- docs/topics/security.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'docs/topics') diff --git a/docs/topics/security.txt b/docs/topics/security.txt index eb1172e7e8..ff33e8be6d 100644 --- a/docs/topics/security.txt +++ b/docs/topics/security.txt @@ -65,10 +65,10 @@ this if you know what you are doing. There are other :ref:`limitations ` if your site has subdomains that are outside of your control. -:ref:`CSRF protection works ` by checking for a nonce in each +:ref:`CSRF protection 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 `, -- cgit v1.3