789016 - When referrer is not set, trying to save changes results in "Permission Denied" error

Status: RESOLVED WONTFIX

(developer.mozilla.org Graveyard :: Editing, defect, P3)

Description

[Marc-Aurèle DARCHE]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20100101 Firefox/15.0
Build ID: 20120824154833

Steps to reproduce:

I have tried to modify the following pages on MDN:

https://developer.mozilla.org/en-US/docs/Command_Line_Options
https://developer.mozilla.org/en-US/profiles/madarche
https://developer.mozilla.org/fr/docs/User:madarche


Actual results:

The "EDIT" button displays and I'm able to modify the HTML content through the CKEditor, but when activating the "SAVE CHANGES" button I have received the following "Permission Denied" page all the time:

Permission Denied

We're sorry madarche, we're afraid we can't do that.

    Log out to try again.
    View demos or browse docs

No computer has ever made a mistake or distorted information. We are all, by any practical definition of the words, foolproof and incapable of error. So it can only be attributable to human error. If so, file a bug for my human operators.



Expected results:

I used to be able to modify many pages on MDN before the switch to Kuma.

This is the first time I start to re-edit pages after the Kuma switch.

Comment 1

[Eric Shepherd [:sheppy]]

I think we've had this happen to one or two other users. One of you knows how to fix it, IIRC.

Comment 2

[Luke Crouch [:groovecoder]]

Have you tried signing out and back in again?

Comment 3

[Marc-Aurèle DARCHE]

(In reply to Luke Crouch [:groovecoder] from comment #2)
> Have you tried signing out and back in again?

Hello,

I have signed out (logout) from MDN as well as from https://login.persona.org/ , quit Firefox and then signed in again. Then I have been greeted with the exact same Permission Denied page.

Comment 4

[Luke Crouch [:groovecoder]]

I just added the "add revision" permission to your account, though you shouldn't need that to make revisions.

What changes did you try to make - content changes, tag changes, review changes?

Comment 5

[Marc-Aurèle DARCHE]

(In reply to Luke Crouch [:groovecoder] from comment #4)
> I just added the "add revision" permission to your account, though you
> shouldn't need that to make revisions.
> 
> What changes did you try to make - content changes, tag changes, review
> changes?

I actioned the "EDIT" button, then I edited the HTML text through the CKEditor, then I actioned the "SAVE CHANGES" button.

I've done just that again after your permission change and I'm receiving the same Permission Denied page.

I did try the "SAVE AND KEEP EDITING" button which produces no error, it even saves a draft. But then again trying to "SAVE CHANGES" causes the return of the Permission Denied page.

Thanks for bearing with me.

Comment 6

[Marc-Aurèle DARCHE]

I've done another test today with a newly created Firefox profile without any addon: and I could edit the https://developer.mozilla.org/en-US/docs/Command_Line_Options page on MDN.

So I guess the problem lies in a combination of privacy settings and addons (usually I use NoScript with mozilla.org and persona.org in the white list). I need more time to investigate and precisely pin what's causing the problem. I'll report when it's found.

Comment 7

[Marc-Aurèle DARCHE]

I've nailed the problem:

The "Permission Denied" page is displayed whenever a "SAVE CHANGES" is attempted with the following option:

network.http.sendRefererHeader = 0

cf. 
http://kb.mozillazine.org/Network.http.sendRefererHeader
https://developer.mozilla.org/en-US/docs/Mozilla/Preferences/Mozilla_networking_preferences

quote :
"
Those concerned with privacy can set this to 0, realizing that this may adversely affect some sites. Those wanting to ensure compatibility should leave it at the default.
"

Since there's an easy workaround (setting network.http.sendRefererHeader = 2) I've lowered the importance of this bug to minor.

But still:

* at least the "Permission Denied" page should at least give the reason why the permission is denied
* why could it be legitimate to disallow page modification to a client which is not sending the Referer header? Is the Referer header used to target the document to modify? I would really recommend another simpler design. Could you please explain?

Thanks

Comment 8

[Les Orchard [:lorchard]]

If I understand the issue, this is actually a fairly old known-bug with Django CSRF protection. It requires a valid referer for use in building the anti-CSRF token when dealing with forms. No referer means no anti-CSRF token can be built, and so form submissions are not accepted.

Comment 9

[Les Orchard [:lorchard]]

See also:
https://bugzilla.mozilla.org/show_bug.cgi?id=718522#c8

I think the only solution is to revisit changing CSRF libraries once bug 731209 is fixed.

Comment 12

[John Karahalis [:openjck]]

Looks like bug 853955 might be a duplicate. Ben added some good detail there.

https://bugzilla.mozilla.org/show_bug.cgi?id=853955#c0

Comment 13

[Ben Bucksch (:BenB)]

I can no longer edit.
Yes, indeed, I have referers disabled, out of conviction, for many many years.
See http://www.apps.ietf.org/rfc/rfc2616.html#sec-15.1.3
Quote from the HTTP spec:
> Because the source of a link might be private information or might reveal an otherwise
> private information source, it is strongly recommended that the user be able to select whether
> or not the Referer field is sent. For example, a browser client could have a toggle switch for
> browsing openly/anonymously, which would respectively enable/disable the sending of
> Referer and From information. 

This used to work fine on MDC (the old one?).

Thanks, lorchard, for comment 8 and 9. I hope this can be fixed quickly.

Comment 15

[John Karahalis [:openjck]]

Bumping up the priority, given the number of duplicates here.

Comment 16

[James Bennett [:ubernostrum]]

Les, in comment 9, hits the problem; though Django's CSRF module has changed since this bug originally opened, it still has this issue.

Comment 22

[Ben Bucksch (:BenB)]

(In reply to John Karahalis [:openjck] from comment #15)
> Bumping up the priority, given the number of duplicates here.

Please fix this. See also spec mentioned in comment 13 about importance.

Comment 23

[:Hb]

I get the same permission error when trying to change the email in MDN even with referrer send (network.http.sendRefererHeader is 2). Normal MDN content is editable when the referrer is set. So this bug is a different issue from the email changing issue described in bug 906883. 

The reporters of the bugs below might test if they can change their email with referrer set to prove this. 
Bug 898393 - Changing my Email address doesn't work
Bug 890993 - Problems signing in with my second registered e-mail account
Bug 876314 - Changing email address results in permission denied

Comment 24

[Marc-Aurèle DARCHE]

Tested again today.

I confirm that email changing with referer send has nothing to do with this present bug 789016. This ticket is only about no referer blocking modifications.

I confirm that this present bug 789016 is still present: i.e. with "network.http.sendRefererHeader = 0" when I want to save a modified page on MDN I got the "Permission Denied" message. And when reinitializing to the default value of "network.http.sendRefererHeader = 2" I have my modified pages saved without error message.

Comment 25

[Ben Bucksch (:BenB)]

This continues to be a big annoyance for me and reduce my level of contribution to MDN. Could you please fix this? Thanks.

Comment 26

[Kohei Yoshino [:kohei]]

+1

I'm tired of this issue and mostly stopped contributing to translation on MDN.

Comment 27

[Luke Crouch [:groovecoder]]

Mentoring this for now in case someone else wants to tackle it before we can get on it.

Comment 28

[Les Orchard [:lorchard]]

I think this depends on a django upgrade, which isn't something I think I can do single-handedly

Comment 29

[Ben Bucksch (:BenB)]

Why is that? Does https://github.com/mozilla/django-session-csrf require a newer Django than you run?

Until this is fixed, could you please simply turn off whatever "protection" is turned on and using the referer?

Comment 30

[James Bennett [:ubernostrum]]

Disabling CSRF protection is not an option. Until we can sort this out, it's better to be inconvenient for people who disable referers than it is to be exposing users to the real threat of attack.

Comment 31

[David Bruant]

(In reply to James Bennett [:ubernostrum] from comment #30)
> Disabling CSRF protection is not an option. Until we can sort this out, it's
> better to be inconvenient for people who disable referers than it is to be
> exposing users to the real threat of attack.
Which threat is that?
The only threat I can think of is that a malicious person creates a webpage on another domain with a <form> pointing to the MDN edit POST URL and maliciously submitting on behalf of already-logged-in MDN users. This requires of course that already-logged-in MDN users get fished into going to this page.
It would be quite a targeted attack and I seriously doubt this would happen before Kuma can be upgraded to Django 1.5 (even if that happens in 2 years).

Did I miss a threat or am I underestimating the threat of removing the current "protection"?

Comment 32

[Luke Crouch [:groovecoder]]

You understand the threat correctly. But CSRF attacks are very serious - e.g., if an MDN admin/super-user stumbles onto a malicious page, an attacker could potentially perform any action available to a super-user.

A CSRF attack against this $edit view may not seem serious, but it could have devastating effect on the wiki content. Like, deleting the entire wiki. :(

Comment 33

[David Bruant]

(In reply to Luke Crouch [:groovecoder] from comment #32)
> A CSRF attack against this $edit view may not seem serious, but it could
> have devastating effect on the wiki content. Like, deleting the entire wiki.
> :(
Hadn't anticipated this. Withdrawing what I said ealier.
CSRF protection shouldn't require a given referrer, but if that's the way it's implemented now, it's worth keeping until something better is deployed.

Thanks for the explanation!

Comment 34

[Ben Bucksch (:BenB)]

lorchard, my needinfo was for this question:
> > Does https://github.com/mozilla/django-session-csrf require a newer Django than you run?

Comment 35

[Les Orchard [:lorchard]]

(In reply to Ben Bucksch (:BenB) from comment #34)
> lorchard, my needinfo was for this question:
> > > Does https://github.com/mozilla/django-session-csrf require a newer Django than you run?

Yes. Please stop needinfo'ing me on this bug.

Comment 36

[Kohei Yoshino [:kohei]]

I just talked with :groovecoder and looks like this can be solved with the updated django.

Comment 37

[Luke Crouch [:groovecoder]]

It looks like the django update has fixed this. I was able to edit https://developer.mozilla.org/en-US/docs/User:groovecoder with no referer set.

Comment 38

[Kohei Yoshino [:kohei]]

I still get an error with referer disabled :-(

Comment 39

[Tanvi Vyas[:tanvi]]

I can't sign in with referrers disabled.

Comment 40

[Tanvi Vyas[:tanvi]]

(In reply to Tanvi Vyas [:tanvi] from comment #39)
> I can't sign in with referrers disabled.

Once I do login (after turning referrers on temporarily and then disabling them again), I get permission denied when I try to edit a page.

Comment 42

[John Whitlock [:jwhitlock]]

We've recently updated Django to 1.11, and I wanted to see if this bug still happens. It does, and it appears that it is forbidden by design. Here are my steps:

In FF Dev Edition 62.0b9:

1. Log out of https://developer.mozilla.org
2. Search "What is my referer", click link to https://www.whatismyreferer.com/. Referer is shown as search engine
3. Load about:config, go to Network.http.sendRefererHeader, set to 0 to disable referrer.
4. Search "What is my referer", click link to https://www.whatismyreferer.com/. Response is "No referer / hidden"
5. Go to https://developer.mozilla.org/en-US/docs/User:groovecoder
6. Click Edit. Next page is "Please Sign In"
7. Click "Sign in with GitHub". Browser flashes a few times, and I'm in the editing view.
8. Made an edit, and clicked save. Next page is "Permission Denied"

The response for editing the page (Step 6) includes setting a csrftoken cookie. This cookie is returned with the POST request to save the page, as well as a csrfmiddlewaretoken in the POST form data. It appears the CSRF token is correct, and it is the referer mismatch that is the issue.

The issue does not reproduce in the development environment. According to the Django documents, the referer heading is only checked when SSL is enabled:

https://docs.djangoproject.com/en/2.0/ref/csrf/#how-it-works

I agree with groovecoder, CSRF protection is important, and I'm not ready to second-guess the Django developers on this one. Here's a discussion of the "why" of this check:

https://security.stackexchange.com/questions/96114/why-is-referer-checking-needed-for-django-to-prevent-csrf

Firefox has a config network.http.referer.XOriginPolicy that appears nicer, allowing you to remove the referer header when the domain doesn't match. The most restrictive option 2, Full host name must match, would allow editing, and still drop the header for non-domain images and search engines.

A possible mitigation would be to warn the user on the edit page that the Referer header wasn't included, and the edit will fail. This could be implemented as a generic form error.

Comment 43

[BMO Automation]

MDN Web Docs' bug reporting has now moved to GitHub. From now on, please file content bugs at https://github.com/mdn/sprints/issues/ and platform bugs at https://github.com/mdn/kuma/issues/.