See bug 649520
Whiteboard: u=user c=security p= → u=user c=security p=2
There's a conflict here, in that some of our existing code relies on django.utils.thread_support, which doesn't exist *after* Django 1.2, but django-session-csrf requires django.utils.crypto which doesn't exist *before* Django 1.3. So there's currently no way for us to integrate this. What we probably want is a bug for migrating to Django 1.3+, and have that be a blocker for this one; once that part's sorted out, switching to the session CSRF middleware is easy (and see the branch named for this bug in my repo for the code).
Component: Website → Landing pages
Product: Mozilla Developer Network → Mozilla Developer Network
Whiteboard: u=user c=security p=2 → u=user c=security specifications
Priority: -- → P1
Whiteboard: u=user c=security specifications → [specification-like][type:feature]
Whiteboard: [specification-like][type:feature] → [type:feature]
One hangup of django-session-csrf is that it requires some effort to CSRF-protect anything that a non-logged-in user would do. So far as I can tell, in kuma that only happens in two places: user signup, and user login. Which means we have a couple options: 1. We could just turn off CSRF protection for those views. I don't know what the security implications of that would be. 2. We can CSRF-protect them, but doing so requires us to make sure we are (and I'm pretty sure we are) set up to handle that with respect to the cache requirements for it.
We should CSRF protect sign-in - we use it to change the email address for accounts.
Bug 789016 blocks several contributors from MDN. Requiring a referer is a HTTP specification violation (see mentioned bug for references). Thus, this is a serious bug, not just a "nice to have" feature.
Severity: enhancement → normal
(In reply to Ben Bucksch (:BenB) from comment #4) > Bug 789016 blocks several contributors from MDN. Requiring a referer is a > HTTP specification violation (see mentioned bug for references). Thus, this > is a serious bug, not just a "nice to have" feature. +1 Is upgrading to django-session-csrf on the roadmap?
Is there any way to increase the priority of this bug? We shouldn't require users to turn referrers on and decrease their privacy in order to contribute to MDN. Browsers don't have a per origin referrer value override, so re-enabling referrers on MDN means re-enabling referrers everywhere.
You need to log in before you can comment on or make changes to this bug.