submit proposal for restrict-referrer-leakage to the CSP standardizers and implementors

[zooko]

In comment:31:ticket:127 and later comments on #127, David-Sarah has written a proposal for a CSP directive to restrict Referer (sic) header leakage. This would be a great fix for issue #127 if it were widely supported. Let's urge browser makers and standards bodies to support it!

[zooko]

I recently learned from Brad Hill that it is possible for end-users using Firefox to impose CSP policies:

​https://blog.mozilla.org/tanvi/2012/09/18/user-specified-content-security-policy/

[davidsarah]

Replying to zooko:

I recently learned from Brad Hill that it is possible for end-users using Firefox to impose CSP policies:

​https://blog.mozilla.org/tanvi/2012/09/18/user-specified-content-security-policy/

There is incidentally already a Firefox pref that allows to never send the Referer header: ​network.http.sendRefererHeader = 0. Although the ability for end-users to specify CSP policy is interesting for us browser security geeks, it's no easier for security and privacy-conscious Firefox users than setting that pref. The advantage of a CSP policy is that:

a) It just works (on new enough browsers) for sites that need it, without the user having to do anything.

b) It won't be specific to Firefox or any other single browser.

c) The Referer header is only one of several misfeatures that leak the referring site (and potentially the exact URL, when the site is displaying untrusted content). My proposal fixes all of the leaks I know of that are standard parts of HTML5, and states that implementors should apply equivalent policies to any non-standard features (so that other referrer leaks contrary to the policy can be treated as security bugs).

d) It cannot break sites that hypothetically depend on Referer for intra-site links. I think that such sites are almost entirely fictional (and any few that exist deserve to be broken), but browser implementors are invested in such fictions and are therefore are unlikely to make not sending Referer the default, whereas the CSP approach is more politically acceptable.

Part of me rails against writing a spec designed for political acceptability when I know the right thing to do instead (never send Referer, and plug the other cross-origin referrer leaks), but if it helps to stop users getting shafted by this long-standing privacy and security bug, I suppose it's worth it. The ​draft spec at least says that it only specifies an upper bound on when you can leak referrers, i.e. it's always conformant to leak in fewer cases.

[zooko]

This Firefox add-on named "refcontrol" seems pretty good:

​http://www.stardrifter.org/refcontrol/

I've been using it. There are plenty of sites in my experience that would break with the network.http.sendRefererHeader = 0 tweak. Those ones break when you put refcontrol into the "send nothing" mode, but some of those work when you put it into the "send just the domain part" mode. It also offers "sending this specific string" mode, can be configured to behave differently on different sites, and can optionally display "What I will send in Referer" on the "add-ons display bar" at the bottom of the page.

I configured it many weeks ago to "send just the domain part" by default, and for my children's elementary school district's web site, to send the full normal Referer. Since then I've never had a problem as far as I know, and no Referer's have been sent except to my children's elementary school district. Victory!

[ChosenOne]

I am using refcontrol for a few years now. only had problems with pictures on one German site, that nobody uses anymore anyway. I am also using the setting that sends "just the domain part" - but note that it sends the domain of the current(!) host, not of the referring site. This means that when I go from example.com to other.com, Firefox will tell other.com that you have just come from other.com.

Now, that I think of it, this add-on might break naive CSRF-mitigations that check whether the Referer header matches the current domain

[gdt]

It strikes me that having to fix this is a clue that putting security-sensitive content in URLs isn't a good idea, or at best a fragile plan. Perhaps capabilities should be treated like passwords within the web world?

[zooko]

gdt: one place to put capabilities that other tools would treat with a little more care is in the URL fragment, i.e. the part of the URL that comes after the #. The URL fragment is never sent in the Referer field, for one thing: ​https://tahoe-lafs.org/trac/tahoe-lafs/ticket/127#comment:13

[freddyb]

Is this obsoleted with the Referrer Policy proposal? It'sj ust a first public working draft so far, but looking for suggestions in www-tag, for example.

​http://www.w3.org/TR/referrer-policy/

[meejah]

Ticket retargeted after milestone closed