Breaks websites with strict CSP policies

[da2x]

1. Install extension, leaving default settings ("Block requests for missing resources" is disabled)
2. Visit https://trends.builtwith.com/Server/Fedora

Expected: Pretty graph.

Actual: Graphs fails to load.

The library is blocked from loading from the CDN by the extension, and the website itself blocks the replacement library from loading from the extension. (If I’m understanding the situation correctly.)

Proposed solution: Unless Block requests for missing resources is enabled, the extension should parse the Content-Security policy HTTP header (or meta element if no header) before blocking the request and attempting to replace it.

Decentraleyes 1.3.8, Firefox 53.0

Possibly introduced via #130.

Console output:

Content Security Policy: The page’s settings blocked the loading of a resource at data:application/javascript;charset=UTF-... (“script-src https://trends.builtwith.com 'unsafe-inline' https://cdnpi.pe https://d2z0lf9itclnw8.cloudfront.net https://www.google-analytics.com https://ajax.googleapis.com https://www.googleadservices.com”). (unknown)
ReferenceError: $ is not defined[Learn More]  bw4.min.js:1:1752
ReferenceError: $ is not defined[Learn More]  Fedora:499:1

[ghost]

In which case adding the problematic domain to Decentraleyes' 'Exclude domains from inspection' list will solution the problem. I just added trends.builtwith.com and https://trends.builtwith.com/Server/Fedora displays the graph correctly, which it didn't otherwise, indeed. This is the first on the list as far as I'm concerned but I admit that strict CSP policies are an issue with Decentraleyes' very way of working.

[j000]

Well I now have issue with https://cdnjs.com. Seems to me like it's same problem.

So when more sites enable strict CSP more sites will break?

[da2x]

So when more sites enable strict CSP more sites will break?

Indeed. Which is why I suggested:

[Decentraleyes] should parse the Content-Security policy HTTP header (or meta element if no header) before blocking the request and attempting to replace it.

[da2x]

Here is another affected page (jQuery loading from Decentraleyes’ origin is blocked by the website’s CSP.)
https://scotthelme.co.uk/content-security-policy-an-introduction/

[RoxKilly]

uBlock Origin v1.13 just added ability to modify a page's CSP header (release notes). Can the code used there be adapted to improve DecentralEyes and fix this issue? Or can uBlock Origin users make use of this new functionality somehow to implement a workaround to this issue?

[Mattwmaster58]

The sites mentioned here all work for me with the web-ext beta (2.0.0beta3, FF 58a1)

[ghost]

Having the same issue, have to disable the addon to use cdnjs.

https://i.imgur.com/BgCSwU7.png

[gwarser]

"Page CSP should not apply to content inserted by content scripts."
https://bugzilla.mozilla.org/show_bug.cgi?id=1267027

[meskarune]

@gwarser if this is an upstream issue, does that mean people should add onto that? The issue was reported 2 years ago, I am not sure how likely it is to be fixed any time soon.

[gwarser]

@meskarune someone is working on this, check comment 21 and following.

[Synzvato]

First off, thanks everyone for adding your personal findings to the discussion!

I'm happy to say that from v2.0.0 onward, Content-Security-headers no longer affect injections. The only security measures that still interfere with injections, are integrity and crossorigin attributes.

Part of the underlying issue has been fixed, and only a handful of sites seem to be affected. This will surely change, once more sites start implementing the aforementioned attributes. Solving the remaining problems is top-priority. The prototypes look promising, and updates will be posted in issue #16.

@gwarser Although it's good that bug #1267027 is being addressed, it's unrelated to the issues that are currently affecting Decentraleyes. It only affects extensions that load content scripts into pages.

[RoxKilly]

@Synzvato wrote:

it's unrelated to the issues that are currently affecting Decentraleyes. It only affects extensions that load content scripts into pages.

Doesn't Decentraleyes load substitute scripts when it blocks CDN requests?

[Synzvato]

@RoxKilly

Doesn't Decentraleyes load substitute scripts when it blocks CDN requests?

Even though it does load substitute scripts, said resources are not injected as content scripts. Doing so would subject any injected libraries to various limitations, mostly related to DOM access.