As I understand (a), it sounds like an excellent scheme, and something that would be simple to update behind the scenes without unduly affecting application code. I'm more ambivalent about (b). Have you or anyone else started work on a patch/pull-request for this?
On Sat, Jul 27, 2013 at 7:12 PM, Shai Berger <s...@platonix.com> wrote: > Hi everybody, > > TL;DR: A simple change can make Django's CSRF protection a little better; > an > additional, slightly less simple one, can also make it look better. > > Django's CSRF protection scheme is a bit unusual; unlike most such > schemes, it > does not rely on a value stored in the server that needs to be matched by a > submitted token and is replaced with every submission, but rather on a > constant value stored in a cookie. This generally works (for details of how > and under what conditions exactly, see [1]), but has two minor problems: > > 1) It is unusual, and in particular diverges from what OWASP[2] > recommends[3]; > as a result, security analysts often think it is not secure. They have been > proven wrong in all cases members of core are aware of, but proving it > again > and again is a nuisance, and there may be bad PR related to this. > > 2) It carries a "second-order" vulnerability: If your site has been > compromised (XSS, Man-in-the-middle, or server compromise) then you become > persistently vulnerable to CSRF. All of these vulnerabilities are way worse > than CSRF and render all CSRF protection schemes worthless while they last; > the point is *not* that they allow CSRF, but rather that they allow CSRF > to be > performed after the main hole has been plugged. This is because the > attacker > can use the main vulnerability to "steal", or even set, csrftoken cookie > values, which they can then use later. After a successful attack of this > magnitude, you need to reset the csrftoken cookies of all users, and this > is > neither obvious nor straightforward to do. > > Django's unique scheme does have two advantages over the more common > solutions, which we would like to keep: > > 1) It is not tied to sessions, users, or site-stored per-user data, > allowing > CSRF protection to a wider range of users > > 2) It avoids the problem of having only one "current" token, which causes > the > submission of one form to invalidate forms open in other browser tabs. > > To improve on both problem issues, while keeping the advantages, I suggest > the > following modifications: > > a) Use a signed cookie for csrftoken -- using Django's existing signing > facility[4], this means signing the cookie with the SECRET_KEY from the > settings; so that an attacker cannot set arbitrary cookies, and changing > the > SECRET_KEY after a compromise immeiately invalidates csrftoken cookies. > > b) Optionally allowing time-limited CSRF tokens. Such tokens will be > generated > by adding a parameter of maximum age to the csrftoken tag, and by marking > view > methods (specifically with a decorator, or globally with a setting) as > requiring timed tokens. When this is used, the posted token value will > need to > be different from the cookie value -- to keep advantage 2, the cookie will > still be constant, and expiry time will only be present in the submitted > token[5]. This method breaks the current way we do CSRF-protected AJAX, so > it > will likely stay optional (and opt-in). > > As you may guess, signing the cookie adds an actual iota of security. > Adding > expiry adds very little -- if an attacker has access to the cookie, they > can > usually just ask the site to generate valid tokens for them, so getting any > real protection will require annoyingly short expiry times. But the fact > that > an attacker needs this extra step makes it a tiny bit harder for them and > makes their actions a tiny bit more detectable; and having a constantly- > changing CSRF token may make the whole thing look a little better to naive > analysts. > > I had some help and guidance in drafting this proposal -- you can credit > Donald Stufft, mostly, for any egregious blunder I didn't make. I am still > responsible for the ones I did make. > > Your comments are welcome, > > Shai. > > > [1] https://docs.djangoproject.com/en/dev/ref/contrib/csrf/ -- in > particular, > "how it works" and "limitations" > > [2] https://www.owasp.org > > [3] > https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet > > [4] https://docs.djangoproject.com/en/dev/topics/signing/ > > [5] django.core.signing.TimestampSigner signs content with the time of the > signature, and then takes a max_age in its unsign() method; the suggested > method would go the other way around, timestamping the token with the time > of > expiry, to allow checking without using data stored on the server (and to > allow different forms to use different max-age values). > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
