Last Comment Bug 1267027 - Page CSP should not apply to content inserted by content scripts.
: Page CSP should not apply to content inserted by content scripts.
Status: NEW
triaged
: meta
Product: WebExtensions
Classification: Components
Component: General (show other bugs)
: unspecified
: Unspecified Unspecified
P3 normal with 54 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: David Durst [:ddurst] (Regression Engineering Owner for 63)
Mentors:
: 615708 1267291 1363139 1366467 1400924 1419678 (view as bug list)
Depends on: 965637 1420155 1446231 1207394 1406278 1407056 1415352
Blocks: 1355213 webext webext-port-tampermonkey
  Show dependency treegraph
 
Reported: 2016-04-23 22:27 PDT by Kris Maglione [:kmag]
Modified: 2018-11-12 10:42 PST (History)
95 users (show)
kmag: qe‑verify-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: 48.3 - Apr 25
Points: ---


Attachments

Description User image Kris Maglione [:kmag] 2016-04-23 22:27:53 PDT
+++ This bug was initially created as a clone of Bug #1207394 +++

This is a follow-up to bug 1254194 comment 29.

In Chrome, web page CSP is not supposed to apply to content inserted by a content script. So, the following should all work, in theory:

* Injecting an inline <script> node should execute the script in a page with "script-src 'none'"
* Injecting an image from "http://example.com" into a page with "default-src 'self'" should load the image.

The following do not work in Chrome, but they seem to prefer that they would:

* Injecting a node with an "onclicked" listener into a page with "script-src 'none'" does not execute the listener, because the script is not executed during the call from the content script that created it.
Comment 1 User image Kris Maglione [:kmag] 2016-04-25 15:11:57 PDT
*** Bug 1267291 has been marked as a duplicate of this bug. ***
Comment 2 User image Kris Maglione [:kmag] 2016-04-25 15:13:28 PDT
Dan, do you have any thoughts on how much of this behavior we want to copy? I'm actually not inclined to implement it at all, except to the extent that add-ons should be allowed to inject resources packaged with the extension.
Comment 3 User image Daniel Veditz [:dveditz] 2016-04-26 18:46:55 PDT
We favor the desires of the user above the page author. We usually assume that the add-on is acting on the user's behalf (the user chose to install it) so it'd be nice if add-ons could bypass CSP. Although sometimes they do slimy stuff for themselves so it's also nice when what they're doing is explicit so reviewers can check it out.

We also are fighting an architecture that is hard to change. If something sticks in an <img> tag, that results in an image load generated by that page. At the networking/nsIContentPolicy level where CSP is enforced we can't tell the difference between script in the page creating that <img> tag and an add-on or chrome creating it.

This is not special to web extensions, and we have essentially this feature request for regular add-ons on file somewhere; I'd call this a dupe of that one. But you're here and seem to have the energy to fight this battle so here are two possible ways to "fix" it.

a) What I've suggested before is to add a method to the internal CSP that lets us expand the policy, rather than the current mechanism that only lets additional content policies tighten the policy. So a Flickr mashup could call this API and add "img-src *.flickr.com" or maybe "all-src *.flickr.com" (I just made up all-src -- we'd need something to override all policies, not a default to be used if other policies weren't set). For WebExtension and Add-on SDK addons this override could be in the add-on metadata (e.g. manifest.json) and easy to review for sanity.

b) I don't think we know in all the places, but it's possible that for DOM-based insertion (as opposed to parser-based like setting innerHTML) we still know the script principal by time we're calling AsyncOpen2 and can use that rather than the page principal. I get 167 non-test hits for AsyncOpen2 so this would be a painful and error-prone approach.
Comment 4 User image Kris Maglione [:kmag] 2016-04-27 14:07:05 PDT
OK, I'll try to figure out how doable this is, then.

I think we should still respect some restrictions, though, and at least forbid loading non-secure resources into secure pages with policies that forbid it.
Comment 5 User image github 2016-05-17 22:49:01 PDT
I'm facing the same problem right now with my extension. I would opt for bypass CSP. As Daniel Veditz mention, the user chose to install the add-on with all pros (new features...) on cons (permissions request...). So CSP is just another entry on that list, depending on your point of view part of pro or con ;)

What would be a good workaround around this to bypass the CSP? I was thinking about using a background script, but that sounds like a lot of overhead just to make my extension working in Firefox.
Comment 6 User image jshackles 2016-07-02 12:15:07 PDT
Any word on when this might get fixed?  Several of my addon's beta testers are running into this bug, and a lot more of the regular users will probably be experiencing it next month when Firefox 48 releases.
Comment 7 User image Kris Maglione [:kmag] 2016-07-02 14:00:31 PDT
This won't be fixed any time in the next few months.
Comment 8 User image The 8472 2016-08-13 15:52:00 PDT
A possible solution: Provide an API to convert blobs to moz-extension: URIs. AIUI those URIs bypass CSP, unlike blob: URIs. So images could be downloaded as blob via XHR, converted to an extension URI and then injected as <img src="moz-extension:...">

It requires extra work by addon authors, but that way the browser won't have to track which parts of the DOM would have to be treated as privileged somehow. The concept of DOM ownership is murky anyway. It's a shared resource between addons and the page.


An alternative would be an API that allows addons to whitelist patterns of content they intend to load into a page. The downside is that it is more coarse-grained than the blob approach and thus increases the potential exploit surface - but only by the whitelist - for malicious scripts that makes it into the site.
Comment 9 User image Kris Maglione [:kmag] 2016-08-13 15:55:36 PDT
(In reply to The 8472 from comment #8)
> A possible solution: Provide an API to convert blobs to moz-extension: URIs.
> AIUI those URIs bypass CSP, unlike blob: URIs. So images could be downloaded
> as blob via XHR, converted to an extension URI and then injected as <img
> src="moz-extension:...">

It would be much easier to just treat blobs with moz-extension: origins as CSP-exempt, like we do for moz-extension: URLs themselves. Feel free to file a separate bug for that, and I'll look into implementing it.

> It requires extra work by addon authors, but that way the browser won't have
> to track which parts of the DOM would have to be treated as privileged
> somehow. The concept of DOM ownership is murky anyway. It's a shared
> resource between addons and the page.

This is something that we're going to have to do regardless.
Comment 10 User image Andy McKay 2017-02-27 11:16:48 PST
Possible dupe mentioned in comment 3 is bug 615708.
Comment 11 User image Andrew Swan [:aswan] 2017-05-08 13:39:23 PDT
*** Bug 1363139 has been marked as a duplicate of this bug. ***
Comment 12 User image Kris Maglione [:kmag] 2017-05-20 10:12:22 PDT
*** Bug 1366467 has been marked as a duplicate of this bug. ***
Comment 13 User image The 8472 2017-05-30 12:34:31 PDT
On the GM issue tracker[0] the idea was brought up to inject per-userscript nonces into each -src rule of CSPs for each page load which could then be exposed to content scripts via an API. I think this is cleaner than "DOM ownership" because ownership could easily lead to transitive privilege leaks if that also applies to <script> or <iframe> elements.


[0] https://github.com/greasemonkey/greasemonkey/issues/2046#issuecomment-304908132
Comment 14 User image Bryan Clark (DevTools PM) [:clarkbw] 2017-06-22 14:55:10 PDT
It looks like the Augury team has run into this issue where they can't inject their own scripts via a content script.

https://github.com/rangle/augury/blob/dev/src/content-script.ts#L32
Comment 15 User image Kris Maglione [:kmag] 2017-06-22 14:59:05 PDT
(In reply to Bryan Clark (DevTools PM) [:clarkbw] from comment #14)
> It looks like the Augury team has run into this issue where they can't
> inject their own scripts via a content script.
> 
> https://github.com/rangle/augury/blob/dev/src/content-script.ts#L32

Content from extensions should be immune to CSP. They just can't inject web content which would violate a page's CSP.
Comment 16 User image Rory O’Kane 2017-06-23 13:25:41 PDT
Bug 866522 is related; it’s about JavaScript in bookmarklets instead of in WebExtensions. The fixes for both bugs probably share a lot of the same work.
Comment 17 User image Kuba Niewiarowski 2017-08-12 20:21:24 PDT
Duplicate of bug 615708?

Also related to bug 1389874.
Comment 18 User image :Harald Kirschner :digitarald 2017-09-20 21:45:09 PDT
This is breaking crucial devtools extensions on CSP secured pages.

Redux:
  Filed in https://github.com/gaearon/redux-devtools/issues/380#issuecomment-329085853
  Script is injected here: https://github.com/zalmoxisus/redux-devtools-extension/blob/ec3c33d7e2db17df13d3dfe06d02e12da3feee6c/src/browser/extension/inject/pageScriptWrap.js#L10

Augury
  :clarkbw mentioned in Comment 14 with code linked similar to the inject pattern from Redux.

More addons that are not converted to extensions yet will run into this.

ni? :mconca for input on prioritizing this from a web extension product perspective.
Comment 19 User image :Harald Kirschner :digitarald 2017-09-21 13:03:47 PDT
*** Bug 1400924 has been marked as a duplicate of this bug. ***
Comment 20 User image Rob Wu [:robwu] 2017-09-22 06:00:43 PDT
The CSP spec is explicit about whether CSP should affect extensions:
https://www.w3.org/TR/CSP/#extensions

> Policy enforced on a resource SHOULD NOT interfere with the operation of user-agent features like addons, extensions, or bookmarklets. These kinds of features generally advance the user’s priority over page authors, as espoused in [HTML-DESIGN].
> 
> Moreover, applying CSP to these kinds of features produces a substantial amount of noise in violation reports, significantly reducing their value to developers.
> 
> Chrome, for example, excludes the chrome-extension: scheme from CSP checks, and does some work to ensure that extension-driven injections are allowed, regardless of a page’s policy.
Comment 21 User image Mike Conca [:mconca] 2017-09-25 15:18:58 PDT
Thanks to everyone for the constructive comments. We are currently targeting to have this feature land in 58.
Comment 22 User image The 8472 2017-09-25 23:56:28 PDT
I think general support for all DOM elements created by content scripts to bypass CSP is dangerous. For example if someone includes some javascript library that is written with the expectation to run in a regular web page in a content script context and that library goes ahead and tries to use <script> tags to load code then you'll suddenly have javascript executing in the untrusted page context.

At least for the specific case of <script> tags any bypass should be opt-in or require extension-specific APIs to work.

I also have concerns about other tags such as <img src="...">, specifically that it does not obscure the included URL. If blob URI + CSP nonce were the norm there would be less information leakage by default.

This is probably not a top concern for most extensions, but since we have no overlays that are invisible to content at least some content-blocking or privacy-focused extensions probably want to reveal as little information as possible to the web content which could report those modifications back to the server.
Comment 23 User image Kris Maglione [:kmag] 2017-10-09 14:15:44 PDT
*** Bug 615708 has been marked as a duplicate of this bug. ***
Comment 24 User image Martijn 2017-10-16 02:30:00 PDT
Why are addon script inserted as page scripts in the first place? Addons are supposed to be application-wide.
Comment 25 User image angelsl 2017-10-16 02:32:58 PDT
This bug refers to content scripts which are injected into page context so that the addon can interact with the DOM and page scripts. Not addons themselves.
Comment 26 User image Martijn 2017-10-16 02:35:50 PDT
Why are they injected into the page? How come an addon can't just interact with a page without modifying it?
Comment 27 User image angelsl 2017-10-16 02:42:51 PDT
It can. But if you want to inject content into the page, then you're modifying the page. Now what happens if you inject content that loads resources from locations the page's CSP doesn't allow?
Comment 28 User image Anthony Lieuallen 2017-10-25 06:54:21 PDT
I was pointed here by someone in IRC.  I'm finding that both content scripts registered in `manifest.json` and calls to `tabs.executeScript()` fail for pages with a strict CSP.

For the manifest case:
https://github.com/greasemonkey/greasemonkey/issues/2631
We register a script which `"matches": ["*://*/*.user.js"],` but navigate to a matching URL with a strict CSP, like https://raw.githubusercontent.com/reek/anti-adblock-killer/master/anti-adblock-killer.user.js , and the script does not run.

In the case of `tabs.executeScript()` we get an error that says "Missing host permission for the tab" despite having the "<all_urls>" permission.


So I guess I'm implicitly blocked from injecting content (which I'm not really even trying to do) because I can't even run the script that would be doing such injecting.
Comment 29 User image Kris Maglione [:kmag] 2017-10-25 10:41:50 PDT
(In reply to Anthony Lieuallen from comment #28)
> I was pointed here by someone in IRC.  I'm finding that both content scripts
> registered in `manifest.json` and calls to `tabs.executeScript()` fail for
> pages with a strict CSP.
> 
> For the manifest case:
> https://github.com/greasemonkey/greasemonkey/issues/2631
> We register a script which `"matches": ["*://*/*.user.js"],` but navigate to
> a matching URL with a strict CSP, like
> https://raw.githubusercontent.com/reek/anti-adblock-killer/master/anti-
> adblock-killer.user.js , and the script does not run.
> 
> In the case of `tabs.executeScript()` we get an error that says "Missing
> host permission for the tab" despite having the "<all_urls>" permission.

CSP doesn't affect content script execution at all. In any case, I can't
reproduce this issue with a simple test extension. Can you provide a complete
testcase?
Comment 30 User image Anthony Lieuallen 2017-10-25 11:21:56 PDT
(In reply to Kris Maglione [:kmag] (long backlog; ping on IRC if you're blocked) from comment #29)
> Can you provide a complete testcase?

See bug #1411641 for more detailed steps including reduced reproduction case.
Comment 31 User image marius.santa 2017-11-02 07:51:09 PDT
Where can this be tested? Is it implemented somewhere?
Are the tests from bug #1411641 valid? I am asking because of https://bugzilla.mozilla.org/show_bug.cgi?id=1411641#c4.
So far I have https://bugzilla.mozilla.org/show_bug.cgi?id=1400924 and https://bugzilla.mozilla.org/show_bug.cgi?id=615708, are these scenarios valid?
Do you have any other scenarios and web extension examples I can use?
Comment 32 User image ggrossetie 2017-11-17 08:47:16 PST
This is also breaking the live preview of the Asciidoctor extension.
Code can be found here: https://github.com/asciidoctor/asciidoctor-chrome-extension/

The following URL should be rendered but nothing happens: https://raw.githubusercontent.com/asciidoctor/asciidoctor/master/README.adoc

Since the CSP on GitHub is really strict, I believe that the content scripts are not executed.

Content-Security-Policy	default-src 'none'; style-src 'unsafe-inline'; sandbox
Comment 33 User image Kris Maglione [:kmag] 2017-11-17 09:07:50 PST
(In reply to ggrossetie from comment #32)
> This is also breaking the live preview of the Asciidoctor extension.
> Code can be found here:
> https://github.com/asciidoctor/asciidoctor-chrome-extension/
> 
> The following URL should be rendered but nothing happens:
> https://raw.githubusercontent.com/asciidoctor/asciidoctor/master/README.adoc

This is a mostly unrelated issue. See bug 1411641.
Comment 34 User image ggrossetie 2017-11-18 09:27:28 PST
(In reply to Kris Maglione [:kmag] (long backlog; ping on IRC if you're blocked) from comment #33)
> This is a mostly unrelated issue. See bug 1411641.

Indeed thanks for the pointer.
I've also noticed that my extension is not able to load Google Fonts:

```
Content Security Policy: The page’s settings blocked the loading of a resource at https://fonts.googleapis.com/css?family=Varela+Round|Open+Sans:400italic,700italic,400,700 (“style-src https://gitlab.com 'unsafe-inline' https://gl-static.global.ssl.fastly.net”).
```

The CSP on this page (gitlab.com) is:

```
Content-Security-Policy: object-src 'none'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://gl-static.global.ssl.fastly.net https://www.google.com/recaptcha/ https://www.gstatic.com/recaptcha/; style-src 'self' 'unsafe-inline' https://gl-static.global.ssl.fastly.net; img-src * data: blob:; frame-src 'self' https://www.google.com/recaptcha/; frame-ancestors 'self'; connect-src 'self' https://gl-static.global.ssl.fastly.net wss://gitlab.com https://sentry.gitlap.com https://customers.gitlab.com; report-uri https://sentry-infra.gitlap.com/api/3/csp-report/?sentry_key=a664fdde83424b43a991f25fa7c78987
```

Given the error message, we can see that the CSP of the page is applied to the content inserted by my content scripts.
Comment 35 User image Kris Maglione [:kmag] 2017-11-18 09:38:41 PST
(In reply to ggrossetie from comment #34)
> (In reply to Kris Maglione [:kmag] (long backlog; ping on IRC if you're
> blocked) from comment #33)
> > This is a mostly unrelated issue. See bug 1411641.
> 
> Indeed thanks for the pointer.
> I've also noticed that my extension is not able to load Google Fonts:
> 
> ```
> Content Security Policy: The page’s settings blocked the loading of a
> resource at
> https://fonts.googleapis.com/css?family=Varela+Round|Open+Sans:400italic,
> 700italic,400,700 (“style-src https://gitlab.com 'unsafe-inline'
> https://gl-static.global.ssl.fastly.net”).
> ```

This should work if you bundle the CSS in your extension, after bug 1415352 is fixed. The exemption that allows extensions to load blocked stylesheets doesn't extend to content loaded by those stylesheets.
Comment 36 User image ggrossetie 2017-11-18 09:58:50 PST
Ok, so in other words, I can't use @import in my stylesheets but I can use url with a "local" path (ie. the font is bundled in my extension), correct ?
Comment 37 User image Kris Maglione [:kmag] 2017-11-22 08:18:31 PST
*** Bug 1419678 has been marked as a duplicate of this bug. ***
Comment 38 User image :Harald Kirschner :digitarald 2018-03-23 08:59:52 PDT
Per :ckerschb, Bug 965637 should eliminate these kind of problems.
Comment 39 User image claudio.vallesi 2018-06-23 16:15:07 PDT
Any progress on this? Specifically I find overkill to block unsafe_inline on style-src at all.
Comment 40 User image Jules RANDOLPH 2018-08-26 08:54:34 PDT
Any updates? I want to run userscripts on a CSP-protected domain with restrictive script-src policies. And I cannot ; it feels like Firefox endorses the site strict policy instead of empowering the user.
Comment 41 User image ExE Boss 2018-08-26 08:56:52 PDT
(In reply to Jules RANDOLPH from comment #40)
> Any updates? I want to run userscripts on a CSP-protected domain with
> restrictive script-src policies. And I cannot ; it feels like Firefox
> endorses the site strict policy instead of empowering the user.

Can’t you use the the `contentScripts` API¹?

¹ https://developer.mozilla.org/docs/Mozilla/Add-ons/WebExtensions/API/contentScripts
Comment 42 User image Jules RANDOLPH 2018-08-26 09:04:16 PDT
(In reply to ExE Boss from comment #41)
> (In reply to Jules RANDOLPH from comment #40)
> > Any updates? I want to run userscripts on a CSP-protected domain with
> > restrictive script-src policies. And I cannot ; it feels like Firefox
> > endorses the site strict policy instead of empowering the user.
> 
> Can’t you use the the `contentScripts` API¹?
> 
> ¹
> https://developer.mozilla.org/docs/Mozilla/Add-ons/WebExtensions/API/
> contentScripts

Thanks, I will ping Tampermonkey authors.
Comment 43 User image Julien Wajsberg [:julienw] 2018-09-03 00:53:21 PDT
This is still breaking react and redux devtools.
Comment 44 User image danshumway 2018-11-12 09:41:13 PST
> Can’t you use the the `contentScripts` API¹?

My understanding is that contentScripts don't have the same access to objects like ``unsafeWindow``. I'm still looking into the exact details for everything, so it could be that there's a secondary privilege or alternate approach that I'm missing.

Assuming that there isn't, currently this is blocking an extension I use, ViolentMonkey, from allowing scripts to run on sites like Github and Twitter.

I understand and support the security side of things, but it feels like (especially in the case of Twitter) their use of CSP is probably not just about security, but also somewhat about them making it harder for any of their users to significantly alter the page. I would support some kind of security mechanism that didn't allow website operators to decide to hamper a user's ability to build webextensions for that domain that leverage more powerful extension APIs.
Comment 45 User image Rob Wu [:robwu] 2018-11-12 09:50:22 PST
(In reply to danshumway from comment #44)
> > Can’t you use the the `contentScripts` API¹?
> 
> My understanding is that contentScripts don't have the same access to
> objects like ``unsafeWindow``.

See https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Sharing_objects_with_page_scripts
Comment 46 User image danshumway 2018-11-12 09:53:14 PST
(In reply to Rob Wu [:robwu] from comment #45)
> See
> https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/
> Sharing_objects_with_page_scripts

Thanks, will take a look and do some additional research.

Note You need to log in before you can comment on or make changes to this bug.