Opened at 2012-12-05T20:23:29Z
Last modified at 2021-03-30T18:41:12Z
#1890 assigned task
submit proposal for restrict-referrer-leakage to the CSP standardizers and implementors — at Version 2
Reported by: | zooko | Owned by: | davidsarah |
---|---|---|---|
Priority: | normal | Milestone: | soon |
Component: | code-frontend-web | Version: | 1.9.2 |
Keywords: | referer referrer standards capleak research | Cc: | |
Launchpad Bug: |
Description (last modified by davidsarah)
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!
Change History (2)
comment:1 follow-up: ↓ 2 Changed at 2012-12-05T20:24:15Z by zooko
comment:2 in reply to: ↑ 1 Changed at 2012-12-05T22:47:29Z by davidsarah
- Description modified (diff)
- Keywords referrer added
- Milestone changed from undecided to soon (release n/a)
- Status changed from new to assigned
- Summary changed from submit proposal for restrict-referer-leakage to the CSP standardizers and implementors to submit proposal for restrict-referrer-leakage to the CSP standardizers and implementors
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.
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/