Status

7 years ago
3 years ago

People

(Reporter: groovecoder, Unassigned)

Tracking

(Blocks: 1 bug)

Details

(Reporter)

Description

7 years ago
See bug 649520
(Reporter)

Updated

7 years ago
Whiteboard: u=user c=security p= → u=user c=security p=2
Assignee: nobody → jbennett
(Reporter)

Updated

7 years ago
Target Milestone: 1.6 → 1.7
(Reporter)

Updated

7 years ago
Target Milestone: 1.7 → ---
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).
(Reporter)

Updated

7 years ago
Depends on: 703053
Blocks: 718522
Target Milestone: --- → 2.3
(Reporter)

Updated

7 years ago
Target Milestone: 2.3 → ---
(Reporter)

Updated

7 years ago
Depends on: 731209
(Assignee)

Updated

6 years ago
Version: MDN → unspecified
(Assignee)

Updated

6 years ago
Component: Website → Landing pages
Product: Mozilla Developer Network → Mozilla Developer Network
Blocks: 789016
Whiteboard: u=user c=security p=2 → u=user c=security specifications
Priority: -- → P1
Whiteboard: u=user c=security specifications → [specification-like][type:feature]
Assignee: jbennett → nobody
Whiteboard: [specification-like][type:feature] → [type:feature]
Priority: P1 → P2
Assignee: nobody → jbennett
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.
(Reporter)

Updated

5 years ago
No longer depends on: 731209
(Reporter)

Comment 3

5 years ago
We should CSRF protect sign-in - we use it to change the email address for accounts.
Blocks: 900191

Updated

5 years ago
Severity: normal → enhancement
Priority: P2 → --

Comment 4

4 years ago
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
Whiteboard: [type:feature]

Comment 5

4 years ago
(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?

Updated

3 years ago
Assignee: jbennett → nobody

Comment 6

3 years ago
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.