Hi Kent, > 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.
There is a difference between 'sessions' in general and 'django.contrib.sessions'. While I agree that CSRF has less impact if no 'session' is active (setting aside Paul's response regarding spam etc), that doesn't mean we want to tie it to a specific implementation of sessions i.e. django.contrib.sessions, which some people may not want to use. Also, there are the attacks known as 'login CSRF', which you might be unaware of, and which are dangerous even when there is no pre-existing session. As it happens, I believe our previous implementation that was tied to django.contrib.sessions was not vulnerable to login CSRF if you used the provided login functionality, but this was more an accident of implementation, whereas the current system is by design not vulnerable to login CSRF. Luke -- "If your parents never had children, the chances are you won't either." Luke Plant || http://lukeplant.me.uk/ -- 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.
