Refs #16859 -- Updated CSRF FAQ to mention CSRF_USE_SESSIONS setting.

This commit is contained in:
Alasdair Nicol 2017-01-19 20:56:39 +00:00 committed by Tim Graham
parent 1b06d5e6f6
commit 503e944ac7
1 changed files with 5 additions and 2 deletions

View File

@ -527,13 +527,16 @@ Some security audit tools flag this as a problem but as mentioned before, an
attacker cannot steal a user's browser's CSRF cookie. "Stealing" or modifying attacker cannot steal a user's browser's CSRF cookie. "Stealing" or modifying
*your own* token using Firebug, Chrome dev tools, etc. isn't a vulnerability. *your own* token using Firebug, Chrome dev tools, etc. isn't a vulnerability.
Is the fact that Django's CSRF protection isn't linked to a session a problem? Is it a problem that Django's CSRF protection isn't linked to a session by default?
------------------------------------------------------------------------------ -----------------------------------------------------------------------------------
No, this is by design. Not linking CSRF protection to a session allows using No, this is by design. Not linking CSRF protection to a session allows using
the protection on sites such as a `pastebin` that allow submissions from the protection on sites such as a `pastebin` that allow submissions from
anonymous users which don't have a session. anonymous users which don't have a session.
If you wish to store the CSRF token in the user's session, use the
:setting:`CSRF_USE_SESSIONS` setting.
Why might a user encounter a CSRF validation failure after logging in? Why might a user encounter a CSRF validation failure after logging in?
---------------------------------------------------------------------- ----------------------------------------------------------------------