Closed Bug 1294996 Opened 8 years ago Closed 1 year ago

Ignore CSP for blob URIs with moz-extension origin

Categories

(WebExtensions :: Request Handling, defect, P3)

Product:
WebExtensions
Component:
Request Handling
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: bugzilla.mozilla.org, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: triaged) 

In response to bug 1267027 comment 9

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

The intended use-case is to work around CSPs by downloading content via XHR and then putting the extension blob URI into the various attributes that are normally protected by CSP.
A way of creating such blob URIs for the content script would also be necessary.

Is that actually any easier than creating moz-extension: URIs from Blobs?
Priority: -- → P3
After some experimenting with a custom protocol handler it seems like  nsIProtocolHandler.URI_FETCHABLE_BY_ANYONE simply causes it to be treated as same-origin, but this is insufficient if the CSP uses script-src: none or some 3rd party only (no 1st-party scripts). I.e. it doesn't actually bypass CSP, it just happens to work if CSP allows "self".
Component: WebExtensions → WebExtensions: Request Handling
Whiteboard: triaged
See Also: → 1267027
I have the following code in an extension content script:

  const imagePath = browser.extension.getURL("/img/img.png");
  const response = await fetch(imagePath);
  const blob = await response.blob();
  const objectUrl = URL.createObjectURL(blob);
  imageElement.src = objectUrl;

When loading into mozilla.org I get the following warning:

Content Security Policy: The page's settings blocked the loading of a resource at blob:https://www.mozilla.org/c36ca52c-515c-43ae-a1ee-c86a6f500330 ("img-src https://www.mozilla.org https://*.mozilla.net https://*.mozilla.org https://*.mozilla.com data: https://*.optimizely.com https://www.googletagmanager.com https://www.google-analytics.com https://*.tiles.mapbox.com https://api.mapbox.com https://creativecommons.org https://ad.doubleclick.net https://sp.analytics.yahoo.com").

The image is prevented from loading when extensions should override the security model of the page and behave like the browser.

Ideally I would use an out of content overlay but this hasn't been implemented yet.
>  blob:https://www.mozilla.org/c36ca52c-515c-43ae-a1ee-c86a6f500330

This is not a blob URI with an extension origin. You would presumably have to create those URIs in a background page so that they have the right origin. But even then this bug would still have to be implemented.
We had a CSP issue similar to this as we were loading JS and CSS files as blobs which were included in the extension. The trick was to add blob: to the CSP rule in the manifest.json to prevent the error i.e.

"content_security_policy": "script-src 'self' 'unsafe-eval' https://*.ourdomain.com blob:; object-src 'self' https://*.ourdomain.com;",
Loading blob URLs in (trusted) extension contexts is a separate issue from exempting blobs with extension origin from CSP in (untrusted) web content. Sure, one could manipulate the headers and meta tags, but that seems like a security risk for content if an extension gets it wrong.
I think there might be a bug with the error reported too, I should have mentioned that. I didn't have chance to dig further but they were generated correctly.


Also Bug 1267027 should hopefully address this too
(In reply to Jonathan Kingston [:jkt] from comment #7)
> Also Bug 1267027 should hopefully address this too

See comment 0 this bug was explicitly filed in response to a comment in the other bug since that would take more effort and increase potential exploit surface (e.g. confusing an addon into spawning privileged DOM nodes which then load SOP- or CORS-violating content).
Product: Toolkit → WebExtensions
My extension "Worldwide Radio" 
https://addons.mozilla.org/addon/worldwide-radio/

Some radios use HLS stream (example: Radio Capital (Italy)).
but the hls-library recommended by Mozilla ( https://developer.mozilla.org/en-US/docs/Web/Apps/Fundamentals/Audio_and_video_delivery/Live_streaming_web_audio_and_video#HLS ) does not work in WebExtensions:

Error: Content Security Policy: The page’s settings blocked the loading of a resource at blob:moz-extension://58d8b783-8c10-4b1c-b365-058c9fb6df04/5496a970-7784-47e7-8e51-2f65322f30ae («script-src»).

the part of code from hls library:

      var buffer_controller_MediaSource = window.MediaSource || window.WebKitMediaSource;
      // setup the media source
      var ms = this.mediaSource = new buffer_controller_MediaSource();
      ms.addEventListener('sourceopen', this.onmso);
      ms.addEventListener('sourceended', this.onmse);
      ms.addEventListener('sourceclose', this.onmsc);
      // link video and media Source
      media.src = window.URL.createObjectURL(ms);

as @The 8472 told, I moved my extensions "export setting" functionality from browser_action popup to background script to overcome this bug, but lately noticed that some extensions (such as FoxyProxy) do it on browser_action without problem, Don't know how.

See Also: → 1696174
Severity: normal → S3

Hello,

https://cdn.discordapp.com/attachments/812577823599755274/1050478758987042868/image.png

As you can see in the picture web workers are getting blocked because of the Content Security Policy.
Can blob:moz-extension be added to to CSP for extensions?

Please fix this. It prevents us from using qr-scanner in our Alby browser extension (https://addons.mozilla.org/en-US/firefox/addon/alby/), see: https://github.com/nimiq/qr-scanner/issues/217

Hello team, this issue severly limits extension's ability to provide basic features. It's a commonly hit limitation, as file generations fail and even javascript libraries like Tesseract cannot be used locally in extensions.
Can you revise the priority of this issue?

Flags: needinfo?(lgreco)

(In reply to nicram606 from comment #14)

Hello team, this issue severly limits extension's ability to provide basic features. It's a commonly hit limitation, as file generations fail and even javascript libraries like Tesseract cannot be used locally in extensions.
Can you revise the priority of this issue?

I just took a look into tesseract.js options and it seems they provide one that may be helpful to workaround the issue you are hitting on the blob urls:

(I haven't checked if the qr-scanner, or some other js/wasm-based library providing the same functionality supports something similar, but it seems not unlikely to be an enhancement that other libraries besides tesseract.js may be willing to support).

On the more general request to exempt moz-extension blob URLs from CSP checks, in light of the additional restrictions related to remote code execution introduced in manifest_version 3 WebExtensions, it is unlikely that we would broadly exempt moz-extension: blob urls from CSP checks.

The same should be the case for manifest_version 3 extension also on Google Chrome.

Nonetheless we are interested in learning of use cases hitting the issues and help extension developers to look for solutions that could unblock those use cases, on a case by case basis.

And so, even if the team agreed on wontfixing this particular issue related to "exempt all moz-extension: blob urls from CSP checks", use cases that seems to not be possible because currently hitting this kind of issues and didn't got any reasonable way to workaround yet are still valuable to be reported as separate bugs (bugs focused on the particular use case that doesn't seem to be achievable, instead of bugs focused on this particular proposed solution).

Status: UNCONFIRMED → RESOLVED
Closed: 1 year ago
Flags: needinfo?(lgreco)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.