5

I have made a browser extension for both chrome and firefox. The firefox one is developed using Web Extension APIs and so there are minimal code differences in these two extensions. As an important feature in the extension, some HTML elements become part of the webpage through Content Scripts. That also involves loading images which are hosted on some server and served over https. Now, these images are loading fine in chrome when the extension is running on top of twitter and github. But, interestingly, images are not loading at all in firefox when the corresponding extension is running over twitter and github. Even more interesting is the fact that the content-script-policy set by twitter in its response header is prohibiting that image load and hence firefox is behaving correctly. So, my question basically is if Chrome is violating the CSP here?

Attaching the csp set by twitter here--

script-src 'nonce-j0GK1zjoBy82/ZWhR7gw+g==' https://connect.facebook.net https://cm.g.doubleclick.net https://ssl.google-analytics.com https://graph.facebook.com https://twitter.com 'unsafe-eval' https://.twimg.com https://api.twitter.com https://analytics.twitter.com https://publish.twitter.com https://ton.twitter.com https://syndication.twitter.com https://www.google.com https://t.tellapart.com https://platform.twitter.com https://www.google-analytics.com 'self'; frame-ancestors 'self'; font-src https://twitter.com https://.twimg.com data: https://ton.twitter.com https://fonts.gstatic.com https://maxcdn.bootstrapcdn.com https://netdna.bootstrapcdn.com 'self'; media-src https://twitter.com https://.twimg.com https://ton.twitter.com blob: 'self'; connect-src https://graph.facebook.com https://.giphy.com https://.twimg.com https://pay.twitter.com https://analytics.twitter.com https://media.riffsy.com https://upload.twitter.com https://api.mapbox.com 'self'; style-src https://fonts.googleapis.com https://twitter.com https://.twimg.com https://translate.googleapis.com https://ton.twitter.com 'unsafe-inline' https://platform.twitter.com https://maxcdn.bootstrapcdn.com https://netdna.bootstrapcdn.com 'self'; object-src https://twitter.com https://pbs.twimg.com; default-src 'self'; frame-src https://staticxx.facebook.com https://twitter.com https://.twimg.com https://player.vimeo.com https://pay.twitter.com https://www.facebook.com https://ton.twitter.com https://syndication.twitter.com https://vine.co twitter: https://www.youtube.com https://platform.twitter.com https://upload.twitter.com https://s-static.ak.facebook.com 'self' https://donate.twitter.com; img-src https://graph.facebook.com https://.giphy.com https://twitter.com https://.twimg.com data: https://fbcdn-profile-a.akamaihd.net https://www.facebook.com https://ton.twitter.com https://.fbcdn.net https://syndication.twitter.com https://media.riffsy.com https://www.google.com https://stats.g.doubleclick.net https://*.tiles.mapbox.com https://www.google-analytics.com blob: 'self'; report-uri https://twitter.com/i/csp_report?a=NVQWGYLXFVZXO2LGOQ%3D%3D%3D%3D%3D%3D&ro=false;

Please notice "img-src" in this. Another question that bothers me is that the extension also has its own content-script-policy specified in the manifest file. How do these two policies play together?

Xan
  • 74,770
  • 16
  • 179
  • 206
discoverAnkit
  • 1,141
  • 1
  • 11
  • 25

1 Answers1

1

Extensions can override CSP of pages if they really want to, but assuming no such response-header surgery, the page's CSP is still mostly respected.

I've made a recent answer regarding CSP in extensions, and will partly reproduce it here:

There are 3 CSPs at play in extensions:

  • content_security_policy directive only applies for extension's own pages (such as the background page). If not specified, it defaults to script-src 'self'; object-src 'self' and has some restrictions on how it can be modified.

  • Content script context is not subject to this CSP. unsafe-eval is unrestricted (since you can do executeScript with arbitrary code anyway), however, inline script and remote script restrictions just don't apply to content scripts, because:

  • Any script in the DOM of the page, be it inline or <script src="..."> tag is executed in the context of the page itself and is subject to the CSP of the page itself. There is precisely one exception, injecting a <script> /* code */ </script> in the page will bypass inline code restrictions for immediate execution.

Note that all of this covers scripts. I am not sure how images are affected. I don't know any docs that cover this.

Note that extensions in general get to override some web security features, for example CORS.

Community
  • 1
  • 1
Xan
  • 74,770
  • 16
  • 179
  • 206
  • Yes. I read about all this here - https://developer.chrome.com/extensions/contentSecurityPolicy#interactions – discoverAnkit May 17 '16 at 10:39
  • response-header surgery?? Can we change the response headers? – discoverAnkit May 17 '16 at 10:40
  • As far as I have researched, the domains from which images are allowed to be loaded will always be governed by page's CSP -> img-src – discoverAnkit May 17 '16 at 10:42
  • 1
    @ankitG `chrome.webRequest.onHeadersReceived` can rewrite CSP header. – Xan May 17 '16 at 10:42
  • Is it a bad practice to use it? – discoverAnkit May 17 '16 at 10:44
  • @ankitG I would say it's potentially dangerous. – biziclop May 17 '16 at 10:46
  • I would say "yes" (even though just this morning I used it for testing - but fully knowing what I'm doing). You are weakening the security of a third-party page and not limiting this to your own extension. – Xan May 17 '16 at 10:48
  • But if that was the case, why would chrome provide such an API in the 1st place, an api which can be potentially dangerous or which can add security threats. – discoverAnkit May 17 '16 at 10:52
  • 2
    It is dangerous because it is very powerful. With great power comes great responsibility (and install-time warnings). It's all about how you use it. There are specialized extensions that manipulate CSP as their _function_, and that's wonderful. But if your extension overrides CSP willy-nilly just to provide an unrelated function, maybe that's reckless overkill. Or, maybe, that's the only way it can function - but the responsibility is yours. – Xan May 17 '16 at 10:57
  • @Xan I just checked. chrome.webRequest.onHeadersReceived is not including the csp header..it has some 7 common response headers – discoverAnkit May 17 '16 at 11:25
  • 1
    I assure you it does and you can modify it. At least in Chrome. Here's [a sample](https://github.com/PhilGrayson/chrome-csp-disable/blob/master/background.js). – Xan May 17 '16 at 11:28