Rewrite Referer preferences/section

[nodiscc]

The referer section is confusing with a commented out item and should probably be clarified/reworded/completed.

We could rewrite it after the referer section on DXR:

// Prefs allowing granular control of referers
// 0=don't send any, 1=send only on clicks, 2=send on image requests as well
pref("network.http.sendRefererHeader",      2);
// Set the default Referrer Policy to be used unless overriden by the site
// 0=no-referrer, 1=same-origin, 2=strict-origin-when-cross-origin,
// 3=no-referrer-when-downgrade
pref("network.http.referer.userControlPolicy", 3);
// false=real referer, true=spoof referer (use target URI as referer)
pref("network.http.referer.spoofSource", false);
// false=allow onion referer, true=hide onion referer (use target URI as referer)
pref("network.http.referer.hideOnionSource", false);
// 0=full URI, 1=scheme+host+port+path, 2=scheme+host+port
pref("network.http.referer.trimmingPolicy", 0);
// 0=full URI, 1=scheme+host+port+path, 2=scheme+host+port
pref("network.http.referer.XOriginTrimmingPolicy", 0);
// 0=always send, 1=send iff base domains match, 2=send iff hosts match
pref("network.http.referer.XOriginPolicy", 0);

// Controls whether referrer attributes in <a>, <img>, <area>, <iframe>, and <link> are honoured
pref("network.http.enablePerElementReferrer", true);

[pyllyukko]

Related issues:

• Always send a referer but spoof it first #2
• Remove network.http.sendSecureXSiteReferrer #190

[pyllyukko]

I don't think we need any of that. The referer header and how it's currently configured in user.js works perfectly IMO. Doesn't leak any info and doesn't break any sites. I couldn't ask for anything more 😃

Maybe we could remove the commented out network.http.sendRefererHeader and the relating link. Then there should be absolutely nothing confusing about it.

[Atavic]

Pretty open wide choices here, IMHO. Something like

pref("network.http.sendRefererHeader",      1);
pref("network.http.referer.trimmingPolicy", 1);

won't maybe break much.

[pyllyukko]

I have experienced some breakage with network.http.sendRefererHeader == 1.

[pyllyukko]

@nodiscc: Good enough?

[nodiscc]

Yes, since network.http.referer.spoofSource is a master switch to spoof all referers (regardless of origin/destination host/domain/protocol) it makes sense to only use this pref.

But:

• it breaks sites/applications where same-origin referers have legitimate uses (providing redirections or other routing functionality) - eg https://github.com/shaarli/Shaarli/wiki/Troubleshooting#redirection-issues-http-referer, https://github.com/shaarli/Shaarli/search?q=referer
• blocking same-origin referers has no privacy benefit since the server operator can track your requests in the server log.

So what we'd want instead is

• Send real same-origin referers
• Spoof cross-origin referers

Right?

ATM Smart Referer is not e10s-compatible. Finding a way to achieve this with simple Firefox preferences would be great. Or add a note about this problem/known workarounds.

Doesn't leak any info and doesn't break any sites

It does, see above

[fmarier]

Spoofing referrers actually disables the CSRF protections that some websites use. It reduces breakage, sure, but it has a security cost. Also discussed on arkenfox/user.js#5 (comment).

[nodiscc]

Considering this comment and blog post, would you be ok to

• Reopen this issue
• Add a reference link to https://feeding.cloud.geek.nz/posts/tweaking-referrer-for-privacy-in-firefox/ in the Referer paragraph
• Change the referer prefs to just network.http.referer.XOriginPolicy = 2 (Don't send any referers across domains, leave same-domain referers untouched)

?

[pyllyukko]

Reopen this issue

Don't see a reason for that. Proper CSRF protection does not rely (solely) on referer header as it should be implemented with a random token (when used within one site/webapp). Cross-site requests (from one domain to another) can use origin header. If spoofing the referer "breaks" some site's CSRF protection, then it's not implemented properly in the first place, as it shouldn't accept but certain referers.

I haven't encountered any anti-CSRF breakage with network.http.referer.spoofSource.

Add a reference link to https://feeding.cloud.geek.nz/posts/tweaking-referrer-for-privacy-in-firefox/ in the Referer paragraph

Sure.

Change the referer prefs to just network.http.referer.XOriginPolicy = 2 (Don't send any referers across domains, leave same-domain referers untouched)

Don't see a reason for this -> reasoning in my previous comment.

[nodiscc]

I understand your point.

Relying on referers to prevent CSRF is kinda broken in the first place.

Not a big deal, but as I said above I know a few cases where it will break legitimate website functionality (eg. Shaarli relies on referer values to redirect you back where you were before editing a link); would you mind adding

// NOTICE: Might break functionality in applications relying on HTTP referer value

to the referer paragraph in user.js?

Then I could start improving the readme generation script proposed in #229 to generate https://github.com/pyllyukko/user.js#known-problems (Use NOTICE: fields to generate a list of known problems and limitations - I will open another issue for this)

[pyllyukko]

would you mind adding

// NOTICE: Might break functionality in applications relying on HTTP referer value

to the referer paragraph in user.js?

Sure, why not.

[fmarier]

Proper CSRF protection does not rely (solely) on referer header as it should be implemented with a random token (when used within one site/webapp).

I agree with you here. There are however cases where using a token and a cookie isn't possible. Login pages is a common place where referrer checks are done for CSRF purposes (to prevent an attacker from logging you into an account of their choice).

Cross-site requests (from one domain to another) can use origin header.

Except that the origin header isn't yet set in Firefox (I'm working on it) so if you want something that works across browsers, you need to use Referer. This is what Launchpad, Django and Facebook use today.

I haven't encountered any anti-CSRF breakage with network.http.referer.spoofSource.

The problem isn't breakage in this case, it's that the anti-CSRF checks always pass, even in the present of a login CSRF attack. So you're exposing yourself to attacks that would have otherwise been blocked by the referrer check.

[nodiscc]

@fmarier @pyllyukko I have added a commit (fe7555a) which is part of PR #239 :

fe7555a: add network.http.referer.XOriginPolicy: 2 in addition to referer spoofing: Users wanting to disable referer spoofing to workaround listed problems will still be protected against disclosing previously visited pages to target domains when clicking on a link

Is this an acceptable compromise? (referers are still spoofed by default. If users want to disable spoofing, there is still a safety net provided by network.http.referer.XOriginPolicy=2. This follows the same reasoning as several other prefs, notably password manager related ones)

Edit: arkenfox/user.js#5 (comment) reports that XOriginPolicy > 1 sometimes causes breakage. Should I amend my patch fe7555a, and comment out this pref then?

[fmarier]

I have added a commit (fe7555a) which is part of PR #239

That looks good to me.

With respect to enabling both, I would point out that if you're restricting referrers to the same site, then there's not much point in spoofing them because the site already gets the real info via their access log. I personally think you may as well leave the same-origin referrers alone to avoid disabling the anti-CSRF code.

XOriginPolicy > 1 sometimes causes breakage.

The only setting I found that doesn't cause any breakage is the one I added in Firefox 52 (XOriginTrimmingPolicy). That said, I've never had problems logging in anywhere and I use XOriginPolicy = 1.

[nodiscc]

if you're restricting referrers to the same site, then there's not much point in spoofing them

I agree with that and that's why my personal setting is the one you described (don't spoof referers, just don't send them across domains). @pyllyukko expressed referer spoofing would not be disabled in his upstream user.js and that's why I think fe7555a is a reasonable compromise (offer the option to toggle spoofing off while still preventing referer leaks).

I still think spoofing should be disabled but that was already debated :/

My end goal is to make our settings easily diffable and well documented so that users can make informed choices on controversial settings like this.

Thanks François for your work on Firefox and your help here

[pyllyukko]

I haven't encountered any anti-CSRF breakage with network.http.referer.spoofSource.

The problem isn't breakage in this case, it's that the anti-CSRF checks always pass, even in the present of a login CSRF attack. So you're exposing yourself to attacks that would have otherwise been blocked by the referrer check.

Ok now I understand the point. Thanks for the clarification.

Edit: arkenfox/user.js#5 (comment) reports that XOriginPolicy > 1 sometimes causes breakage. Should I amend my patch fe7555a, and comment out this pref then?

I think we shouldn't enable this. I'm pretty sure it will introduce some problems.