Hi Mike, If an attacker can set cookies on your domain, you've got much larger problems than whether or not they know the nonce. Even if you do change the nonce on login, you are still vulnerable to multiple forms of session fixation attacks. To quote myself from an earlier mail to this list:
https://groups.google.com/forum/#!msg/django-developers/3vG7H3kRBZ0/rZmJFazA4YMJ Django's CSRF implementation differs from many others which store CSRF information alongside session information on the server. The CSRF mechanism functions by matching a token provided in a form with a token provided as a cookie in the browser. If you set the cookie to 'zzz', it will still function perfectly well. The security comes from the fact that an attacker cannot set the cookie, not that it happens to contain any specific cryptographic value. Given this property, if an attacker can set a CSRF token cookie, rotating it during login makes no functional difference to your application security. The solution here is to configure your application so that an attacker cannot read or set any cookies. The best way to do this is to enable HSTS including subdomains, get yourself added to the browser pinning lists, make sure your domain contains no XSS bugs, and encourage users with browsers that do not support HSTS to switch to browsers that do. If the specific properties of Django's CSRF implementation do not work for your application, you may be interested in this alternate CSRF middleware implementation: https://github.com/mozilla/django-session-csrf As always, when reporting potential security problems, please use the secur...@djangoproject.com address. Regards, -Paul On Sat, Oct 27, 2012 at 7:01 PM, <mikethom...@tormail.org> wrote: > Hi there, > > I'd like to discuss the behavior of the 'csrftoken' cookie that is used > for django's CSRF protection [1]. > I noticed that the cookie content does not change when performing a login > (like the 'sessionid' cookie does). > According to [1] this seems to be the documented behavior: "This cookie is > set by CsrfViewMiddleware. It is meant to be *permanent*" > but the csrftoken content should change on login (like the sessionid > cookie does). > If the attacker is able to set the cookie (this can happen before the > victim performs the login) he will know the > nonce that is needed to bypass the CSRF protection: > "The malicious user would have to know the nonce, which is user specific > (using a cookie)." [2] > > Do you agree that the 'csrftoken' cookie should be treated like the > session cookie when it comes to fixation attack prevention (cookie should > change on login)? > Can this be fixed directly in the CsrfViewMiddleware or can/should > developers address this in the webapplication? > > kind regards, > Mike > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
