On Fri, 2010-08-27 at 11:20 +0100, Mat Clayton wrote: > I forgot to mention that as well, not to mention that they can be > spooked pretty easily as well, although in this case thats not really > a concern. Any chance of getting some of the core dev's to think about > removing additional SSL checks, as FF 3.6.8 is a pretty major browser > to support and this is likely to only get worse as adoption increases. > Is the additional security worth the trade off?
The additional check is there to stop an active network attack that can otherwise be launched against an HTTPS connection. It goes like this: - MitM intercepts an HTTP request and sends a CSRF cookie and a forged page with the corresponding form token to the user over HTTP. - the page causes the browser to make a request to an HTTPS target. Since it has a token and a matching cookie, it gets past our CSRF defences just fine. The additional security that SSL ought to provide against active network attacks has been removed. The basic flaw is that cookies set over unsecured connections (HTTP) are applied to secured connections (HTTPS). Until all popular browsers treat HTTP and HTTPS cookies completely separately (and I'm not aware of *any* that do this), we are stuck with this problem. So we need this check, otherwise there is a huge hole in HTTPS security. An alternative is to tie the CSRF token to the session in some way, like we used to do in Django 1.0 and 1.1. The reasons we moved away from doing that are documented here: http://code.djangoproject.com/wiki/CsrfProtection BTW, the problem that some users are having is almost certainly not related to firewalls, because they wouldn't be able to tamper with the contents of the HTTPS requests (and we don't do the checks for HTTP). But something running in the browser could do it. Finally, the only time we need Referer headers sent is for same origin requests (POST requests to be exact). Sending the Referer header in this case is virtually never a privacy concern, since the site will already be able to track what other pages you have visited on their site. So, if this turns out to be a problem, we could possibly ask Mozilla (and other browsers) to add special casing for this (e.g. make the 'sendRefererHeader' option only apply to cross domain requests). By the way, we are not the only ones doing this. Other people have suggested that strict Referer checking under HTTPS is a very effective and simple way to combat CSRF [1]. Luke [1] http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf -- Environmentalists are much too concerned with planet earth. Their geocentric attitude prevents them from seeing the greater picture -- lots of planets are much worse off than earth is. 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-develop...@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.
