7 ms·

> To prevent these issues from occurring again in the future, Google has been pushing a "Manifest V3", which (among other, more controversial requirements) bans

by gildas 6y ago

> To prevent these issues from occurring again in the future, Google has been pushing a "Manifest V3", which (among other, more controversial requirements) bans the practice of executing any JavaScript loaded from a remote server It's a bit ironic that this security issue doesn't exist in Firefox [1] when they actually implement features promoted by Google in the Manifest V3. Why doesn't Chrome already block remote scripts? [1] https://blog.mozilla.org/addons/2019/12/12/test-the-new-csp-for-content-scripts/ https://blog.mozilla.org/addons/2019/12/12/test-the-new-csp-...

nugget 6y ago
Wouldn’t this neuter the most useful Chrome extensions? Cash back/coupons, adblock, etc.
- gildas 6y ago
  These extensions don't need to run remote scripts to work properly, and they work perfectly in Firefox. Typically, "legitimate" extensions use remote scripts to dynamically insert trackers or ads.
- SilverRed 6y ago
  You can still return text data, you don't need to execute it.
sneak 6y ago
I really wish we could get something like this for local, desktop apps. I'm super tired of most every new desktop "app" being just an electron runtime (which, of course, can read and write all over my filesystem) that runs now-unsandboxed js both from its own bundle, as well as downloaded willy-nilly from the internet.
- tadfisher 6y ago
  Let's give engineers more credit, here. The majority of desktop applications have the same capabilities, including writing all over your filesystem and executing code from remote sources. Electron gives those same capabilities to apps written in JavaScript.
  - ori_b 6y ago
    Electron: The safety of desktop applications with the user experience of web applications.
    - zeepzeep 6y ago
      So, worst of both worlds?
  - josteink 6y ago
    > Let's give engineers more credit, here. The majority of desktop applications have the same capabilities, including writing all over your filesystem and executing code from remote sources. Capability, sure. But more often than not, it is Electron-based applications which are happy to include remote scripts... Because that's often as easy or easier than vendoring your dependencies and bundling them. In practice, Electron apps probably poses a bigger security risk, at least for that threat-vector.
    - ChrisLTD 6y ago
      On MacOS they could and should be sandboxed by the OS.
    - kevingadd 6y ago
      For a while you could get persistent native code execution (effectively root) in Slack, Discord and Microsoft Teams by dropping a text file in a specific spot in AppData/homedir/etc. Didn't even need to be chmodded or anything, just drop the file there and the electron apps would run it at startup with full permissions. Really dramatically lowered the difficulty of running code on an end-user's machine, especially since that directory is writable by virtually anything, including an electron app you've XSS'd. I think all 3 have been patched to prevent that particular attack, but it's astonishing to me that electron apps don't seem to use any form of code signing. my HackerOne reports were all Out Of Scope, naturally, until parts of the attack got assigned CVEs later and someone else got the bug bounty :) At least it's fixed!
  - kevingadd 6y ago
emptyparadise 6y ago
But think of the great excuse for killing off V2!
fomine3 6y ago
The restriction worth for security, but also pain for some extensions. For example, A Google Translator add-on on Firefox can't be regitered to Mozilla's store. https://github.com/andreicristianpetcu/google_translate_this https://github.com/andreicristianpetcu/google_translate_this
- gildas 6y ago
  Indeed, it is not possible to use Google translate without running a remote script. However, this is not justified from a technical point of view as far as I know.
  - TheGoddessInari 6y ago
    Then how does S3 Translate on Firefox do the same thing & has no trouble being in the store?
    - gildas 6y ago
      They don't have any trouble because they don't run remote scripts. This problem is specific to the implementation (and the TOS) of the Google translate API.
davidzweig 6y ago
Um, question, does remote code (as defined by the Webstore and Mozilla) refer to JS that is downloaded and eval()ed in the background and content script contexts, or <script> tags that are injected into the page, or both?
- cmeacham98 6y ago
  You can't eval in extension context, but injecting a <script> would work given the permission that lets you edit the page's DOM.
  - davidzweig 6y ago
    Ah, thought it was allowed with 'unsafe-eval' in extension CSP. Never had a need for it. Remote code refers to injecting <script> tags into the page then?
    - josteink 6y ago
      When running as a WebExtension you have a higher set of permissions than a regular script (you can to some degree control the browser, after all), so certain parts of JavaScript is off-limits. eval() is one of those things.

by gildas 6y ago

nugget 6y ago

Wouldn’t this neuter the most useful Chrome extensions? Cash back/coupons, adblock, etc.

gildas 6y ago
These extensions don't need to run remote scripts to work properly, and they work perfectly in Firefox. Typically, "legitimate" extensions use remote scripts to dynamically insert trackers or ads.
SilverRed 6y ago
You can still return text data, you don't need to execute it.

sneak 6y ago

I really wish we could get something like this for local, desktop apps. I'm super tired of most every new desktop "app" being just an electron runtime (which, of course, can read and write all over my filesystem) that runs now-unsandboxed js both from its own bundle, as well as downloaded willy-nilly from the internet.

tadfisher 6y ago
Let's give engineers more credit, here. The majority of desktop applications have the same capabilities, including writing all over your filesystem and executing code from remote sources. Electron gives those same capabilities to apps written in JavaScript.
- ori_b 6y ago
  Electron: The safety of desktop applications with the user experience of web applications.
  - zeepzeep 6y ago
    So, worst of both worlds?
- josteink 6y ago
  > Let's give engineers more credit, here. The majority of desktop applications have the same capabilities, including writing all over your filesystem and executing code from remote sources. Capability, sure. But more often than not, it is Electron-based applications which are happy to include remote scripts... Because that's often as easy or easier than vendoring your dependencies and bundling them. In practice, Electron apps probably poses a bigger security risk, at least for that threat-vector.
  - ChrisLTD 6y ago
    On MacOS they could and should be sandboxed by the OS.
  - kevingadd 6y ago
    For a while you could get persistent native code execution (effectively root) in Slack, Discord and Microsoft Teams by dropping a text file in a specific spot in AppData/homedir/etc. Didn't even need to be chmodded or anything, just drop the file there and the electron apps would run it at startup with full permissions. Really dramatically lowered the difficulty of running code on an end-user's machine, especially since that directory is writable by virtually anything, including an electron app you've XSS'd. I think all 3 have been patched to prevent that particular attack, but it's astonishing to me that electron apps don't seem to use any form of code signing. my HackerOne reports were all Out Of Scope, naturally, until parts of the attack got assigned CVEs later and someone else got the bug bounty :) At least it's fixed!
- kevingadd 6y ago

emptyparadise 6y ago

But think of the great excuse for killing off V2!

fomine3 6y ago

The restriction worth for security, but also pain for some extensions. For example, A Google Translator add-on on Firefox can't be regitered to Mozilla's store. https://github.com/andreicristianpetcu/google_translate_this https://github.com/andreicristianpetcu/google_translate_this

gildas 6y ago
Indeed, it is not possible to use Google translate without running a remote script. However, this is not justified from a technical point of view as far as I know.
- TheGoddessInari 6y ago
  Then how does S3 Translate on Firefox do the same thing & has no trouble being in the store?
  - gildas 6y ago
    They don't have any trouble because they don't run remote scripts. This problem is specific to the implementation (and the TOS) of the Google translate API.

davidzweig 6y ago

Um, question, does remote code (as defined by the Webstore and Mozilla) refer to JS that is downloaded and eval()ed in the background and content script contexts, or <script> tags that are injected into the page, or both?

cmeacham98 6y ago
You can't eval in extension context, but injecting a <script> would work given the permission that lets you edit the page's DOM.
- davidzweig 6y ago
  Ah, thought it was allowed with 'unsafe-eval' in extension CSP. Never had a need for it. Remote code refers to injecting <script> tags into the page then?
  - josteink 6y ago
    When running as a WebExtension you have a higher set of permissions than a regular script (you can to some degree control the browser, after all), so certain parts of JavaScript is off-limits. eval() is one of those things.