NoScript WebExtension and its CSP reports

[salim-b]

Describe the issue

I've enabled Block CSP reports so I got an entry no-csp-reports: * true in my rules. Today the NoScript WebExtension for Firefox 57+ came out and I noticed several CSP reports from the domain fake-domain.noscript.net appearing in uBO's logger, e.g.:

Then I found this interview with NoScript's main developer Giorgio Maone in which he says he would be using CSP reports in a "creative" way to rebuild certain of the old extension's features in the WebExtension:

Dynamic permissions for embedded JavaScript are not natively supported by WebExtensions. Rather than requesting a new API, I am using Content Security Policies (CSP), a Web Application Security standard, to control scripting execution and other security properties of the webpage.

Therefore I tried to set the explicit allow rule no-csp-reports: fake-domain.noscript.net false analogous to what's described in uBO's Wiki to allow CSP's for the domain fake-domain.noscript.net only. Now obviously this didn't work because the CSP reports still get blocked by the no-csp-reports: * true rule (at least that's what uBO's logger shows, the same as in the screenshot above).

I don't have enough understanding of the technical details involved to say what's going on/wrong here. As far as I can tell this hasn't caused any practical issue/limitation on my side. But on the other hand I'm still becoming accustomed to NoScript's new – let's say "in need of getting used to" – interface and can't really tell if it works completely as it should (i.e. provides all the protection it should).

Update:
When I allow steemit.com in NoScript, the NoScript CSP reports don't show up but ones from steemit.com instead:

So I guess uBO's logger "wrongly" allocates the Steemit's CSP reports to the NoScript domain/can't allocate them to the actual domain they're originating from?

Besides that, I've noticed that when a site like Steemit is blocked in NoScript, noscript.net appears as a blocked third-party domain in uBO's panel (and allowing it doesn't do nothing, i.e. still red/blocked).

Update 2:

NoScript's CSP reports only fire when the first party domain is not whitelisted in NoScript. This might result in fake-domain.noscript.net being able to reconstruct the browsing history as gorhill warns in this comment.

Update 3:

According to a statement from Giorgio Maone there's no privacy issue (browser history leakage):

"fake-domain.noscript.net", as the name implies, is a domain which does not resolve to anything, and since noscript.net is under my control I can make sure nobody makes it real domain. It's used as the report URI for the script-blocking CSP, in order to catch LOCALLY whatever has been blocked by NoScript and show it in the UI. As soon as the request is initiated, is processed LOCALLY by NoScript and blocked, so the information never leaves the browser. If, by accident (e.g. because you disable NoScript while a page with the CSP loaded is still active) the CSP report is fired and not caught, as I said the domain doesn't resolve and the request just times out.

One or more specific URLs where the issue occurs

E.g. this site: https://steemit.com/spanish/@vieira/el-materialismo-el-mayor-problema-de-la-sociedad

Your settings

• OS/version: Ubuntu 16.04 LTS x64
• Browser/version: Firefox 57.0
• uBlock Origin version: 1.14.18

Your filter lists

Enabled all built-in filter lists, minus:

• Adguard Mobile Filters​​​​​​​​​
• Fanboy’s Social Blocking List​​​​​​​​
• the country specific filters (except DEU)

Your custom filters (if any)

Disabled them all, issue still occurs.

Besides I'm using "AAK-Cont Filter For uBlock Origin​" with Greasemonkey (the new WebExtension).

[gorhill]

So I guess uBO's logger "wrongly" allocates the Steemit's CSP reports to the NoScript domain/can't allocate them to the actual domain they're originating from?

How did you come to this conclusion?

Why not a more simple explanation which matches what logger is reporting you?

The report to steemit.com is the result of the server steemit.com asking to have CSP violations reported to its server. Your logger shows that uBO is injecting a neutered version of Google Analytics script, hence this triggers a spurious CSP violation: steemit.com serves a CSP header, and part of the CSP header is report-uri /api/v1/csp_violation (use the browser's network pane to see headers). This is what you see in the logger.

[salim-b]

The report to steemit.com is the result of the server steemit.com asking to have CSP violations reported to its server. Your logger shows that uBO is injecting a neutered version of Google Analytics script, hence this triggers a spurious CSP violation

This (which the logger only shows when a site is allowed by NoScript -> 2nd screenshot) I understand since I actually took the time to read the Wiki entry about CSP reports.

How did you come to this conclusion?

Ehm, looking at what the logger reports when a site is blocked by NoScript (1st screenshot)? I don't understand why fake-domain.noscript.net is reported as the domain. Also I don't understand why noscript.net appears as a blocked third-party domain in uBO's panel when a site is blocked in NoScript (this hasn't been the case before the transition to WebExtensions).

[gorhill]

By the way, when you use no-csp-reports: fake-domain.noscript.net false, it means "do not block CSP reports when visiting fake-domain.noscript.net". These are per-site switches, where the "per-site" part refers to the site you are currently visiting.

So mainly this means that uBO's feature of blocking CSP reports is incompatible with NoScript's uses of CSP reports.

Not sure at this point how this could be made compatible, aside not using the feature to block CSP reports in uBO.

[gorhill]

Maybe I could change the semantic of no-csp-reports from testing 1st-party hostname to testing 3rd-party hostname. I have to think about it to see if this would be "ugly" conceptually. It does feel this would make sense.

[salim-b]

By the way, when you use no-csp-reports: fake-domain.noscript.net false, it means "do not block CSP reports when visiting fake-domain.noscript.net". So mainly this means that uBO's feature of blocking CSP reports is incompatible with NoScript's uses of CSP reports.

Ah, that at least clears things a bit up, thanks.

Maybe I could change the semantic of no-csp-reports from testing 1st-party hostname to testing 3rd-party hostname. I have to think about it to see if this would be "ugly" conceptually. It does feel this would make sense.

Unless you don't want to introduce a source-destination-semantic like in dynamic filtering rule syntax this sounds reasonable. But what do I know 🙈 Thanks for looking into this in any case!

[gorhill]

I will change the semantic, it makes more sense after all, and this is a good time to do it while the CSP report-blocking feature is really one single checkbox.

So this goes from

"Block all CSP reports when visiting such site"

to

"Blocks all CSP reports to such server"