Open Bug 1411641 Opened 2 years ago Updated 3 months ago
CSP 'sandbox' directive prevents content scripts from matching, due to unique origin, breaking also browser features [Screenshots]
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0 Build ID: 20171003101214 Steps to reproduce: NOTE this may sound like bug #1267027 but it is not. More context: https://github.com/greasemonkey/greasemonkey/issues/2631 1) Install Greasemonkey 4.0alpha8 ( https://addons.mozilla.org/en-US/firefox/addon/greasemonkey/versions/beta?page=1#version-4.0alpha8 ) 2) Navigate to https://gist.github.com/arantius/f6fd80b1efad368a45ca35567bc31b18 3) Click "raw" Note that the result is served with: $ curl -vs "https://gist.githubusercontent.com/arantius/f6fd80b1efad368a45ca35567bc31b18/raw/107eb46664238549969e67b7a22d747cc7517f78/red-border.user.js" 2>&1 | grep -i 'content.security' < Content-Security-Policy: default-src 'none'; style-src 'unsafe-inline'; sandbox Actual results: In Firefox 56 ( Built from https://hg.mozilla.org/releases/mozilla-release/rev/8fbf05f4b92125e081984f5e39b559b83e5cc729 ) and 57 nightly ( Built from https://hg.mozilla.org/mozilla-central/rev/a29052590fc6538b89641e690d11731ca8e78120 ) I navigated to the text source of the JS file, the content script did not run, so my extension feature was not available. Expected results: In Firefox 54 ( Built from https://hg.mozilla.org/releases/mozilla-release/rev/90f18f9c15f7c71c755e387cfc193974fcf8b29c ) AND 55.0.3 ( Built from https://hg.mozilla.org/releases/mozilla-release/rev/10a244c0f835d286d49a571dab59b698d7404e28 ): Greasemonkey's registered content script ( https://github.com/greasemonkey/greasemonkey/blob/b27e7aed4f3ca2822a3ba67d59dbda5fcd048d71/manifest.json#L46 ) ran, and the user script installation dialog was shown. This should work for all, especially current, versions of Firefox.
Install attached extension (possibly unpacked). Run attached python server. Navigate to http://localhost/open.user.js and see alert Navigate to http://localhost/closed.user.js and see no alert
CSP does not apply
Summary: REGRESSION: Page CSP blocks extension content script → CSP 'sandbox' directive prevents content scripts from matching, due to unique origin
FYI this also breaks `tabs.executeScript()` on such tabs, but from the update it sounds like the same fix should fix both.
2 years ago
Component: Untriaged → DOM: Security
Product: Firefox → Core
Status: UNCONFIRMED → NEW
Component: DOM: Security → WebExtensions: Request Handling
Ever confirmed: true
Product: Core → Toolkit
We're seeing the same issue with Stylus. It won't style raw gist pages: > it doesn't load any content scripts on raw gist page and if I try to inject CSS manually via `browser.tabs.insertCSS` it says "Error: Missing host permission for the tab", which is absurd since Stylus has `<all_urls>` permission. Ref: https://github.com/StylishThemes/GitHub-Dark/issues/550#issuecomment-339426189
@andym Why is this marked as wontfix for Fx57? 57 will be the first release with WebExtensions-only support, and this is preventing a very popular extension from behaving properly.
Firefox 57 was merged onto beta several months ago as per the calendar schedule here: https://wiki.mozilla.org/RapidRelease/Calendar
Many Problems with this CSP thing! Crazy example: We can't style AMO pages too ... Please provide a general and easy way to authorize an user to toggle and fine tuning CSP. Firefox 57 break to many things and don't give to us any choice. Now i use Waterfox (and keep an eye on my poor Firefox)
(In reply to decembre56 from comment #10) > We can't style AMO pages too ... That has nothing to do with CSP but a deliberate restriction on AMO pages to prevent access to certain APIs. This is documented here: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Content_scripts. Please note Chrome has a similar restriction, where you cant run content scripts in Chrome on the Chrome store either.
Am I correct in assuming we can't add any scripts now at all from github on the newest version of Greasemonkey? Nor create a local script anymore? I can imagine users would only want to upload scripts to github, not userstyles.org or others.
(In reply to sten from comment #12) > Am I correct in assuming we can't add any scripts now at all from github on > the newest version of Greasemonkey? That is correct. The only way right now would be to go to `about:config` and *temporarily* disable `security.csp.enable`. So set it to false, then refresh the script on GitHub, install the script, and then set `security.csp.enable` back to `true` (do *not* leave it disabled just for this). As for creating local scripts, there does not seem to be a functionality yet to create blank scripts in GM4.
(In reply to Patrick Westerhoff from comment #13) Thanks for the response. Apparently tampermonkey is able to pop up an installation dialog for github hosted scripts. I don't know about the inner workings of either add-on, but maybe they have a workaround for this bug that might be worth looking into.
Greasemonkey picked a "content script" as a way to detect installation, because it is straightforward and easy to implement. Without knowing that this bug exists. There's plenty of ways to trigger script installation, I just got unlucky.
Confirming issue on FF 58.0.2 and disappointment at the progress made into fixing it.
Confirming issue still present in Firefox 59.0 (In reply to Patrick Westerhoff from comment #13) >`security.csp.enable`. So set it to false, then refresh the script on GitHub, install the script, and then set >`security.csp.enable` back to `true` (do *not* leave it disabled just for this). I've tried this, but as soon as `security.csp.enable` is back to `true` the issue reappears.
(In reply to Jet from comment #18) > I've tried this, but as soon as `security.csp.enable` is back to `true` the > issue reappears. Yes, because this issue is not fixed. Turning off CSP will allow you to install scripts. After installing them, you should turn CSP back on. Of course, turning it on again will prevent you from installing scripts again. – My point was that you should not leave CSP disabled just for the convenience of being able to install scripts.
I'm having this issue in my extension that inject STYLE (not even <SCRIPT>) into a website after the user save an URL from which loading the CSS source.
Any plan to fix this, or at least a work-around? It's obviously causing severe issues with NoScript as well, see https://forums.informaction.com/viewtopic.php?f=7&t=24994
That's worrying indeed. Might other add-ons that block things be affected by this issue as well, such as Ublock or Umatrix?
Firefox screenshots also does not work!
(In reply to kernp25 from comment #27) > Firefox screenshots also does not work! It works fine here with 60.x and 61.x and 62.0b5 all (64-bit) on Windows 10 1709, What OS are you using? Have you fiddled with about:config disabling something screenshots requires?
(In reply to Jet from comment #28) > (In reply to kernp25 from comment #27) > > Firefox screenshots also does not work! > > > It works fine here with 60.x and 61.x and 62.0b5 all (64-bit) on Windows 10 > 1709, > Are you sure you're talking in the context of this bug? Anything that relies on content scripts, including Mozilla's internal add-ons which more and more Firefox features are based on like Screenshots, are broken by this: 1. Open https://www.dropbox.com/help/security/enable-two-step-verification 2. Try to take a screenshot from the Page Actions menu (the drop-down from the navigation bar) 3. Watch the notification "Whoa! Firefox Screenshots went haywire." Reproducible on both Firefox 61, 62.0b5 and Nightly 63.0a1 (2018-07-05).
OS: Unspecified → All
Hardware: Unspecified → All
Summary: CSP 'sandbox' directive prevents content scripts from matching, due to unique origin → CSP 'sandbox' directive prevents content scripts from matching, due to unique origin, breaking also browser features [Screenshots]
Version: 56 Branch → Trunk
I'm putting this in the General component (i.e. not webRequest/webNavigation) because this bug is about content scripts, not webRequest. Web pages that use frames with the sandbox attribute suffer from the same issue.
Component: Request Handling → General
See Also: → 1475831
You need to log in before you can comment on or make changes to this bug.