#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):
Replying to [comment:29 lukeplant]:
> a page on `attacker.example.com` could send a header like this `Set-
Cookie: csrf=myval,domain=.example.com`.
But in that case, you can just use a pre-fabricated cookie and token.
Just access the site once in advance to get a cookie and token that match
up.
Similar problems happen (as described in the PDF you linked) with HTTPS.
A MITM attack, using HTTP, could set the CSRF cookie; then, even if your
sensitive forms are HTTPS, you could still CSRF into HTTPS using the
cookie you MITM'd earlier.
This response is getting complicated, so I'm going to enumerate the
attacks being discussed before continuing:
1: A same-domain site sets a known CSRF cookie in order to set a known
CSRF token, and uses it to perform generic CSRF.
2: An active attacker does an MITM to establish an HTTP session, creating
a known CSRF on a user's system. It then performs a CSRF attack on the
user, targetting HTTPS.
3: A same-domain site sets a known CSRF cookie in order to set a known
CSRF token, and then uses that to perform login CSRF.
#1: In principle, this could be fixed by keeping a record of all CSRF
tokens which were supplied for each session. Reject any CSRF token which
has not legitimately been used for a session. This gets complicated; for
example, if the session is reset (creating a new session on logout), the
existing CSRF token needs to be copied over to the new session. I hate
this idea automatically, and I hope there's a better way.
#2: This one is serious in principle. If your site is completely HTTPS,
you reasonably expect CSRF protection to be very strong and not subject to
MITM attacks, but if the attacker can MITM, he can fool a user into
loading an HTTP page to manipulate the CSRF cookie. Probably any fix for
#1 would fix this, too.
#3: If the attacker can manipulate cookies like this, preventing login
CSRF is very difficult. No form of "lock CSRF token to session" works--
the attacker can simply clear the session cookie, since he doesn't care if
the user gets logged out when performing login CSRF. The only way I can
think of (with the CSRF token approach) is to lock the CSRF token to the
user's IP, so an attacker can't use a pre-fabricated CSRF token. This is
unacceptable; some users still have rapidly changing IPs. I suspect this
attack combination (login CSRF + same domain) is narrow enough that not
protecting against it is acceptable, as long as it's documented.
I'm not personally too concerned about same-domain attacks, as long as the
weakness is well-documented. There's a simpler way to fix it: get your
own domain and stop sharing a domain with people you don't trust. (I
don't know all of the issues with cookie domains, though. I know--having
just tried it--that I can't set a domain cookie on a TLD, eg. ".com", at
least in FF. Can a user on www.ed.ac.uk set a domain cookie for
".ac.uk"?)
The MITM case bothers me, though. One "fix" would be to challenge-
response it. One HTTPS request (eg. "checkout") brings up a new form with
a new, one-time-use token; and it has another form (eg. "confirm
purchase") which submits using the one-time token. Of course, almost
every sane online store does this, to prevent duplicating a purchase, and
it'd prevent the MITM issue as well. But it's not a general solution,
since you don't want to have to double-confirm everything.
--
Ticket URL: <http://code.djangoproject.com/ticket/9977#comment:30>
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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---
