This article actually indicates a (probably bug-bounty'able) flaw in the Chrome webstore security checks:
> The script that it fetches from the above server is a malware payload. The extension needs to download it after having been installed because it cannot ship with the payload if it wants to pass through the Chrome Webstore’s security checks.
There probably are legitimate reasons to pull in remote content, but I can't think of any that can't be worked around. You'd think that Google's own malware tracking would pick up http://104.131.35.136:9999/ as a bad site, but the malware author takes care to hide that delivery mechanism behind a header check.
So, to me, ANY request or evals by extensions should (at the very least) be detected and constitute a separate permissions category, or, better yet, BLOCKED as a violation of same origin policy.
I don't get where you're going with this. The extension has the "<all_urls>" permission which explicitly allows it to do this. It also explicitly turned on unsafe-eval.
> The extension has the "<all_urls>" permission which explicitly allows it to do this.
<all_urls> have nothing to do with the browser's normal Same Origin Policy for individual web pages. All URL's indicates that the extension is allowed to operate on all pages loaded in the browser window.
It has nothing to do with the resources loaded by the extension. In other words, I'm talking about (for a start), this "Regular web pages.. limited to Same Origin Policy. Extensions can talk to remote servers outside of its origin."
In other words, extension should be treated as operating within the context of that tab; in other words, a locked-down sandbox for that tab.
Cross-origin permissions as noted above should be flagged to the user and should apply across the board to any injectable resource (including CSS, HTML, Javascript, SVG, etc.)
Otherwise, outside resources should fall into the Same Origin Policy (i.e., if your tab is at https://google.com/, only resources should be loaded from google.com.)
<all_urls> specifically refers to whether the extension is triggered on all URL's that are visited in the browser or not. That permission is usually needed.
Different origin attempts to communicate (read and/or write) any data on its own to any third party server should fall under different permissions.
For more information on what should have happened here, please see "Only local script and and object resources are loaded":
That's a good point, and I agree; in fact, unsafe eval should be only be allowable within the Same Origin Policy.
Also, this brings up another good point: some permissions are more risky than others (for example, the legitimate use cases for unsafe eval are few). A visual indicator of the relative severity of the requested CSP's when installing the extension would probably help less technical people separate when an extension is very risky. (Multiple red danger symbols would probably be a good clue..)
Yes, regular pages are limited to their same origin policy. Extensions, when they request it, are not. This extension requested it, so it is capable of downloading files from any server to a string. It also requested unsafe-eval, this lets it eval a string. Now, when you add one and one together, you have two features combined in a malicious way. But not a bug.
Sure, things should be different. But they are the way they are, and considering the way they are, this is not a bug. And certainly not bug-bounty'able.
> The script that it fetches from the above server is a malware payload. The extension needs to download it after having been installed because it cannot ship with the payload if it wants to pass through the Chrome Webstore’s security checks.
There probably are legitimate reasons to pull in remote content, but I can't think of any that can't be worked around. You'd think that Google's own malware tracking would pick up http://104.131.35.136:9999/ as a bad site, but the malware author takes care to hide that delivery mechanism behind a header check.
So, to me, ANY request or evals by extensions should (at the very least) be detected and constitute a separate permissions category, or, better yet, BLOCKED as a violation of same origin policy.