Paul, thanks for your reply! Comments inline: Paul McMillan <p...@mcmillan.ws> writes: >> Would it not be possible to move the second instance of the nonce (that >> will be compared to the form field) from a cookie to a session variable >> (at least when a session is available)? Would that result in other >> problems instead? > > Yes it's possible, and that's how our CSRF protection worked at first. > However, it has the disadvantage of being tied to sessions, and so our > last revision of the framework specifically decoupled the two.
> One reason you may not want it tied to sessions is if you have a > public comment form on an unencrypted page, but also want to have > SESSION_COOKIE_SECURE, so sessions are never sent unencrypted. Another > is that the extra session lookup for every form submitted may be a > performance problem, depending on how you store your sessions and what > your traffic profile looks like. Another reason is that you may not be > using the sessions framework at all, and still want forms with CSRF > protection. The applications I have in mind (where the "subdomain can set cookies for other subdomains" could hurt) use django.contrib.auth and thus sessions as well. Thus, they already have to do a session lookup for the auth check, haven't they? Could that be reused for the CSRF check? I think it would be OK to have to specify something like a SessionBasedCsrfMiddleware instead of the normal CsrfMiddleware, if the choice between "session" and "cookie" cannot be made dynamically by the framework. Just so I am not missing a class of attacks here: how important is CSRF protection for non-session applications? I have always viewed CSRF chiefly as an attack where you try to fool somebody who is authenticated (and therefore has privileges in the system) to ask the system to do a bad thing by doing the cross-site POST. > Improving the CSRF in this fashion is on my list of things to do, but > it's a bit of a tricky problem, and so it hasn't happened yet. We can > do better than we do now, but not without somewhat changing the > properties of the system. If you would like help with testing etc for this, I hope I can offer some time. BTW, should I submit a ticket about this to the Django ticket database or is there a more general ticket that already covers this? / Kent Engström -- 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.
