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

Status: RESOLVED INCOMPLETE

(Core :: DOM: Security, defect)

Description

[anonbugreport]

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.

Comment 1

[u287251]

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/

Comment 2

[Loic]

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.

Comment 3

[Christoph Kerschbaumer [:ckerschb]]

Kamil, Matt, can we still reproduce this one? If so, we should get it fixed!

Comment 4

[Matt Wobensmith [:mwobensmith][:matt:]]

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.

Comment 5

[Christoph Kerschbaumer [:ckerschb]]

Matt couldn't reproduce the issue. Closing this due to the lack of response from the reporter.

Comment 6

[u287251]

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.

Comment 7

[u287251]

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.