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]

Categories

(WebExtensions :: General, defect, P3)

defect

Tracking

(Not tracked)

People

(Reporter: arantius, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

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.
Attached file repro. extension
Attached file repro. http server
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.
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
Duplicate of this bug: 1412128
Priority: -- → P2
@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.
Blocks: 1334174
Flags: needinfo?(amckay)
Duplicate of this bug: 1425200
Flags: needinfo?(amckay)
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.
Product: Toolkit → WebExtensions
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
(In reply to Giorgio Maone [:mao] from comment #23)
> 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

Hmm this looks serious. So does this mean that those pages aren't rendered at all (and hence no html is displayed, no Javascript is executed), unless they're whitelisted on Noscript? That would be an awful instrument for malicious sites to force users to whitelist their site in Noscript.

Or, worse, is Javascript still executed in the background but the page just isn't displayed?
(In reply to swleefers from comment #24)
> (In reply to Giorgio Maone [:mao] from comment #23)
> > 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
> 
> Hmm this looks serious.

It's mostly a serious usability issue: JavaScript is blocked as expected, but both the popup UI and the placeholders for blocked objects won't work. You cannot know which script sources are blocked on that page, and you can only change permissions (blindly) from the Options page.

There's also a security expectation problem users who block WebGL in the TRUSTED preset or in a CUSTOM setting, because WebGL blocking depends on content scripts.
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?
Flags: needinfo?(kernp25)
(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).
Blocks: 1449052, 1451526
Flags: needinfo?(kernp25)
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
No longer blocks: 1449052
No longer blocks: 1451526
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
Duplicate of this bug: 1489861
Duplicate of this bug: 1517017
Priority: P2 → P3

(In reply to Giorgio Maone [:mao] from comment #29)

(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).

I've just tried this, going through exactly the steps you have provided. On Firefox 67.0.4 (64-bit), Windows 10, taking a screenshot of that page works for me (clicking on the three dots inside the address bar to get the option "Take a screenshot"). Has anything been fixed in Firefox? Or has the Dropbox page dropped its CSP or anything?

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