#9977: CSRFMiddleware needs template tag
---------------------------------------------+------------------------------
Reporter: bthomas | Owner: lukeplant
Status: assigned | Milestone:
Component: Uncategorized | Version: SVN
Resolution: | Keywords: csrf
Stage: Design decision needed | Has_patch: 1
Needs_docs: 1 | Needs_tests: 0
Needs_better_patch: 1 |
---------------------------------------------+------------------------------
Comment (by Glenn):
What bugs me is that swapping out CSRF cookies (with cross-site cookies or
MITM) feels like a regression. Before, if you swapped out the CSRF token,
you had to do so by swapping out the whole session, so you're logging the
user out. That meant you could do login CSRF this way (which you could do
anyway), but nothing else.
> Django it will work slightly differently as a session is created before
the user logs in, not on the POST request that contains the authentication
credentials, which complicates applying that paper directly.
I havn't read the whole thing (like most papers, it's so long the
important points are obscured), but the idea is something like this (which
is a bit easier to think about now that it's been in the back of my mind
for a day):
#1: In CsrfViewMiddleware.process_view, if a session exists and it has a
known CSRF token, it must match the real CSRF cookie. If it doesn't, the
CSRF cookie may have bee nswapped out; reject the request (and flush the
session to recover the user).
#2: In CsrfViewMiddleware.process_response, if there's an existing
session, and it doesn't have a stored CSRF value, copy it.
(To be clear: The CSRF cookie remains the authoritative value of the CSRF
token. The value in the session, if any, only validates the CSRF cookie,
to prevent swaps.)
This would handle session.flush correctly (eg. on login and logout). When
auth.logoout flushes the session, the CSRF cookie is untouched. When we
get to CVM.process_response, the existing CSRF value will be immediately
copied to the new session.
This would handle session expiry correctly. After session expiry, the
CSRF cookie remains. If the user then makes a new request which creates a
new session, the existing CSRF cookie is then added to the new session.
It would also keep contrib.session optional. If sessions aren't being
used, then security against CSRF cookie tampering is lost, but protection
for the major cases (remote CSRF) still works.
I think this would protect against both the HTTP/MITM attack and same-
domain CSRF (not including login CSRF). Let me know if you see any holes.
--
Ticket URL: <http://code.djangoproject.com/ticket/9977#comment:32>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---
