Thanks very much for your reply, knowing the reasoning behind the decisions made really helps.
Cheers, James On 17 August 2013 11:56, Russell Keith-Magee <[email protected]>wrote: > > On Thu, Aug 15, 2013 at 7:21 PM, James Roper <[email protected]> wrote: > >> Hi, >> >> I'm a core dev on Play Framework, and I'm currently looking closely at >> our CSRF protection and making improvements, and so I'm looking carefully >> at what other frameworks do because when it comes to security, it's easy to >> miss something. >> >> I'd like to get a better understanding of the reason behind why >> X-Requested-With is no longer supported in Django. I've read about the >> vulnerability behind it: >> >> https://blog.whitehatsec.com/flash-307-redirect-game-over/ >> >> What I don't understand is why this vulnerability required server side >> fixes. It's clearly a client side vulnerability, here's the Firefox >> version of the vulnerability in the NVD: >> >> http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-0059 >> >> It is clearly stated that the vulnerability is in Firefox, not on the >> server side. Firefox has since fixed the issue. The issue is also fixed >> in Chrome: >> >> https://code.google.com/p/chromium/issues/detail?id=63698 >> >> So what I don't understand is why Django and Rails both raced to fix this >> on the server side? It makes it a pain in both frameworks to do AJAX >> calls, where X-Request-With was such a simple solution. And now that >> clients are fixed, the server side fixes don't seem to be necessary >> anymore. Is there something I've missed? >> >> Yes. Firefox and Chrome have *subsequently* fixed the issue. But you have > no control over user space, and you have absolutely no guarantee that *all* > users are using fixed browsers. Users don't always update browsers when > they're told to, even if you flash a "YOU ARE COMPROMISED! UPDATE!!1!" > banner in front of them. There *were* compromised browsers in the wild, and > we have no reason to believe that *every one of them* has been updated to > remove the problem. > > I completely agree that the AJAX hole was very convenient. However, as a > project, Django wasn't willing to allow *any* possibility of an exploit, > now or in the future, so we had to remove the exception. > > >> Also, was this ever really fixed in Django? Rails stores the token in >> the session, but Django stores the token in a cookie. But since the >> vulnerability allowed setting arbitrary headers, couldn't an attacker just >> set the Cookie header to set the token to be whatever they wanted, and >> submit a token in the form that matched? I ask because Play has an option >> that allows storing the token in a cookie, and I'd like to fully understand >> what if any issues there are with that (I can see from the Django source >> code that mitm attacks with SSL are a big pain to deal with for one). >> > > I'll stand corrected on this, but the vulnerability wasn't about > *completely* arbitrary headers -- it was just the extension headers. To the > best of my knowledge, cookies are still safe -- they can't be set across > domains, unless you have either a MITM attack vector, or a > subdomain/wildcard cookie. > > Yours, > Russ Magee %-) > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Django developers" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/django-developers/75hNjzboNkM/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/django-developers. > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
