Closed Bug 1194970 Opened 9 years ago Closed 8 years ago

[e10s] CSP report-uri uses the original referrer instead of the spoofed referrer written by uMatrix or RefControl

Categories

(Core :: DOM: Security, defect)

42 Branch
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE
Tracking Status
e10s + ---

People

(Reporter: anonbugreport, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [domsecurity-backlog])

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:42.0) Gecko/20100101 Firefox/42.0 Build ID: 20150814004009 Steps to reproduce: Original report to addon developer at https://github.com/gorhill/uMatrix/issues/320 Install uMatrix and enable the "Spoof HTTP Referrer" option. Click a link to https://twitter.com/ which utilizes report-uri in their CSP. Actual results: Network inspector shows that the HTTP referrer is spoofed for the request. However the report-uri JSON payload contains the original referrer. Expected results: The report-uri should use the referrer of the request instead of a original referrer.
Actually this also happens for other extensions which modify the `Referer` header. I tested with the most popular one, RefControl[1], and the issue is also present. [1] https://addons.mozilla.org/en-US/firefox/addon/refcontrol/
The issue is reproducible only with e10s enabled. With e10s disabled in Nightly, the referrer of report-uri is the spoofed referrer chosen in RefControl instead of the original one.
Blocks: e10s
Status: UNCONFIRMED → NEW
Component: Untriaged → Security
Ever confirmed: true
Product: Firefox → Core
Summary: CSP report-uri uses the original referrer instead of the referrer written by uMatrix → CSP report-uri uses the original referrer instead of the spoofed referrer written by uMatrix or RefControl
Summary: CSP report-uri uses the original referrer instead of the spoofed referrer written by uMatrix or RefControl → [e10s] CSP report-uri uses the original referrer instead of the spoofed referrer written by uMatrix or RefControl
Blocks: e10s-addons
No longer blocks: e10s
tracking-e10s: --- → +
Kamil, Matt, can we still reproduce this one? If so, we should get it fixed!
Component: Security → DOM: Security
Flags: needinfo?(mwobensmith)
Flags: needinfo?(kjozwiak)
Whiteboard: [domsecurity-backlog]
I am not able to reproduce this issue on latest Nightly 48.0a1. I used the RefControl addon. With e10s both on and off, the spoofed referrer was present and correct in the payload of the report-uri. Adding a needinfo to the reporter - can you try this again and see if it's been fixed or not? If not fixed, maybe you can also paste in the JSON of the report that is incorrect.
Flags: needinfo?(mwobensmith)
Flags: needinfo?(kjozwiak)
Flags: needinfo?(anonbugreport)
Matt couldn't reproduce the issue. Closing this due to the lack of response from the reporter.
Status: NEW → RESOLVED
Closed: 8 years ago
Flags: needinfo?(anonbugreport)
Resolution: --- → INCOMPLETE
I ran a test case in latest Nightly, and I can confirm the issue is fixed. I tried the same test case for FF 47, but for unknown reasons, I can't see the network request related to the CSP report being reported in the Network pane -- as opposed to Nightly. The test case is simple: if using uBlock Origin ("uBO") + default settings and loading twitter.com, a CSP violation will be triggered by the fact that uBO will redirect the script resource from google-analytics.com to a replacement data: URI-based script. The CSP report-related network request is normally blocked by an EasyPrivacy filter, which I overrid to allow it to go through. Yet, it does not show up in the FF47's Network pane.
Ok, I finally can confirm that it is also fixed with FF 47 -- for some reasons the CSP report is not always reported in the Network console -- possibly a cache-related issue, as if I shift-click the page refresh button, it is always reported.
You need to log in before you can comment on or make changes to this bug.