Referer leak

[quilloss]

Firefox 41.0a2
uMatrix 0.9.2.1
Not a clean profile but since I already typed it out I will post this first then confirm it with a clean profile.
Edit:
Confirmed on a clean profile with only xpinstall.signatures.required = false and spoof referer in uMatrix set.

CSP report-uri
google-analytics.com blacklisted through one of the host files.
Clicking a link to https://twitter.com/ will result in a request to https://twitter.com/i/csp_report containing the true referer in the JSON payload.
Setting network.http.referer.XOriginPolicy = 1 blanks the referer as expected, so I expect that it should be doable in uMatrix too.

Origin Header
Go to https://www.youtube.com/ check the request header of the woff2 requests to fonts.gstatic.com. It includes Origin: https://www.youtube.com. No leak in privacy since both domains are owned by Google but I was sure that I saw this somewhere else before.

[gorhill]

Clicking a link to https://twitter.com/ will result in a request to https://twitter.com/i/csp_report containing the true referer in the JSON payload

Is this network request made from within the behind-the-scene scope?

[quilloss]

Is this network request made from within the behind-the-scene scope?

uBlock says behind-the-scene, uMatrix says tab scope, and Firefox logged it in the page's network inspector.

Also, from which URL did you click the link to Twitter?

The URL on this page does not work? I managed to reproduce the issue on a clean profile using this issue page.

[gorhill]

uBlock says behind-the-scene, uMatrix says tab scope, and Firefox logged it in the page's network inspector.

Ok, there is nothing leaked in there: it's Twitter sending a payload to itself when a CSP directive is violated, which occurs when uBlock/uMatrix block scripts in the current case. Twitter merely sends to itself the current CSP header which caused the violation.

Regarding the Origin header, yes, I need to neutralize this.

[quilloss]

But won't this information "referrer":"https://github.com/gorhill/uMatrix/issues/320" be considered a leak. Why would it be part of the JSON payload if there is no content from Github even present on the page?
Again setting network.http.referer.XOriginPolicy = 1 would make this section become "referrer":"".

[gorhill]

But won't this information "referrer":"https://github.com/gorhill/uMatrix/issues/320" be considered a leak?

Mine was empty. Let me look more into this.

[gorhill]

Ok, I now I see it, don't know why it was not reported previously -- probably hit enter in the address bar instead of refreshing the page.

Reading more into this, it does appear that there is a standard syntax for report-uri, as per MDN:

referrer The referrer of the document in which the violation occurred.

So I fixed the Origin header, and the original referrer still shows in the CSP report, which means the browser keeps and uses the original referrer value regardless of any spoofing of headers -- so the browser appears to use its own internal history data, therefore disregarding user's intent to not leak referrer information.

This occurs only when:

• 1st-party scripts are blocked for the current site (hence uMatrix will inject a CSP script-src directive
• The current site declare a report-uri in its CSP header

For now the proper solution I can think of is to remove the report-uri element for when uMatrix modifies the CSP, in order to avoid spurious CSP violation reports -- and consequently prevent leakage of information.

I could take the opportunity to modernize the CSP injection code to avoid injecting if inline scripts are already forbidden by the site, it's probably going to become a more common occurrence as CSP is becoming more used by web sites.

[gorhill]

Related: #129.

[gorhill]

I need to import the CSP-related changes to uBlock.

[gorhill]

Ugh, the fix works well for Chromium, but not for Firefox: Looks like Firefox's CSP-report-uri feature relies on the original CSP header, never on the modified one. I will need something more to address Firefox's specific behavior.

[gorhill]

Side note for Firefox: with NoScript, the spurious CSP report-related network request also occurs, but as opposed to uMatrix, it occurs if allowing 1st-party scripts on Twitter, whereas with uMatrix it occurs if blocking 1st-party scripts on Twitter.

[quilloss]

Can't you just block all application/json request to the report-uri if it is present. If you want to be extra sure, double check the JSON for the "csp-report" key. Though that may result in logger spam.

[gorhill]

Feedback with the latest changes here.

It appears neutralizing the Origin header will break a lot of pages. For one, Youtube videos wouldn't play anymore with my set of rules, I needed to disabling referrer spoofing. I noticed that when I navigated away from Youtube using a link on a Youtube page, there was no Origin header in the main request for the document on the other site. I will need to read more about this, but for now I have to disable the spoofing of the Origin header, since the end result will be that users will be forced to disable referrer spoofing anyways, opening a larger gap privacy-wise than the current status.

For the other issue with CSP report, I have to figure a solution for Firefox, which may be none than to let the user block these report-uri which are reported in the other column. The current solution works well on Chromium. I believe it is possible that Firefox needs to fix the issue, since NoScript also suffers from it -- though in a different way. Firefox should take into account the modified header value, not the original one, but everything is probably more complicated. Regarding looking up the payload, that would be the worst solution, as I rather have uMatrix stick to handling URL, not the payload a requests (because efficiency).

Outight blocking the URL in report-uri is a solution, but I would have to implement it only for Firefox, as I wouldn't want other browser vendors suffering the added overhead if it's not needed.

Anyways, turns out everything is more complicated than expected.

[gorhill]

Actually, without any extension installed, Firefox fires report-uri network requests for Twitter -- so this has nothing to do with NoScript.

[gorhill]

After giving much thought about the report-uri feature, I am of the opinion a bug should be opened on bugzilla, as the issue affects not only uMatrix, but any extension which purpose is to foil referrer header. Firefox should use the modified headers, after they have gone through whatever extensions, not the original headers.

With Firefox, sites could currently workaround referrer spoofing extensions by purposefully designing themselves to systematically cause CSP violations to be fired every time -- fooling those using a referrer spoofer.

[quilloss]

I am of the opinion a bug should be opened on bugzilla

Ok, bug opened at https://bugzilla.mozilla.org/show_bug.cgi?id=1194970. I hope I got all the details right.

Looks like Firefox's CSP-report-uri feature relies on the original CSP header, never on the modified one.

Did you mean the report-uri relies on the original referrer header instead of the original CSP header? Because when I removed the report-uri from the CSP header using nsIHttpChannel.setResponseHeader Firefox stop firing those reports.

[gorhill]

Did you mean the report-uri relies on the original referrer header instead of the original CSP header?

I mean that report-uri should cause Firefox to use the modified Referer header, not the original one, in the referrer property of the resulting csp-report JSON object.

[gorhill]

Closing this issue as fixed, as the issue is now in Firefox's camp: https://bugzilla.mozilla.org/show_bug.cgi?id=1194970.