Re: CSRF protection and cookies
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.
Re: CSRF protection and cookies
> I had forgot about the Referer header check. It seems that it > would stop the subdomain-to-subdomain CSRF attacks as long as > the site is only using HTTPS, wouldn't it? Yep. I think the balance there makes sense. It would be nice to figure out a good way to do optional checking for non-HTTPS, but really, everyone should be using HTTPS. -Paul -- 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.
Re: CSRF protection and cookies
Paul McMillan writes: > In the meantime, if you use SSL on each of your subdomains, you get > strict checking of the Referer header for CSRF, which mitigates that > particular avenue of attack. Since you're using sessions and auth, you > should be using SSL, and so the protection is mostly free. Of course. The sites I'm thinking of are HTTPS only. I had forgot about the Referer header check. It seems that it would stop the subdomain-to-subdomain CSRF attacks as long as the site is only using HTTPS, wouldn't it? Thanks for your work on 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.
Re: CSRF protection and cookies
> 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? Yes. Unfortunately, the cookie model (and thus your browser) are not really designed to protect you in this situation. We work around it as best we can, but it's an uphill struggle. Yes, it's very possible to tie CSRF to sessions, and the new signing bits make that even better. Django doesn't currently support this feature out of the box, and is unlikely to do so in 1.4. I've put some thought into the design for this, but it's not something I want to rush into, and it's not something that is easy to just tell someone else how to do and let them go implement it. I don't have the time to really turn this into a solid feature before we freeze 1.4. In the meantime, if you use SSL on each of your subdomains, you get strict checking of the Referer header for CSRF, which mitigates that particular avenue of attack. Since you're using sessions and auth, you should be using SSL, and so the protection is mostly free. > 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. Those are the worst sorts of CSRF. CSRF protection also helps prevent spamming, and can discourage reflected DoS attacks. Additionally, CSRF protection can help mitigate the effects of XSS in some cases. > If you would like help with testing etc for this, I hope I can offer > some time. Thanks, I'll take you up on that when I do get a chance to start drafting things. I went ahead and created #16859 to help keep track of these issues. https://code.djangoproject.com/ticket/16859 -Paul -- 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.
Re: CSRF protection and cookies
Paul, thanks for your reply! Comments inline: Paul McMillan 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.
Re: CSRF protection and cookies
> 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. 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. -Paul -- 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.
CSRF protection and cookies
Hi, > Today we've released Django 1.3.1 and Django 1.2.6 to deal with > several security issues reported to us. Details of these issues and > the releases, along with several important advisory notes, are > available in the blog post on djangoproject.com: > > https://www.djangoproject.com/weblog/2011/sep/09/security-releases-issued/ I've been thinking about the problems caused by the CSRF cookies being settable by other servers sharing the same domain name, as mentioned at the URL above: > Advisory: Cross-subdomain CSRF attacks > > Due to the nature of HTTP cookies, a cookie can be set from a subdomain > which will be valid for the entire domain. This means that an attacker > who controls a subdomain can, for example, set a CSRF cookie which will > be valid for the entire domain. If I understand it correctly, our CSRF protection works by putting the same random nonce in a form field and a cookie. The protection comes from the fact that the bad guy can only control the form field but not the cookie. But in the case above, he can control the cookie too and the protection fails. Is that correct? 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? / 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.
