a lot of @electronjs devs have the attitude that their app doesn't need sandboxing or keeping up-to-date with Chromium bc "it doesn't execute untrusted code". the problem is that falls apart as soon as you get XSS. github.com/signalapp/Sign…
(at least Signal has sandboxing)
(at least Signal has sandboxing)
"should i build this as a web app or use Electron?"
the difficulty gap between XSS and full RCE is much smaller in Electron compared to a browser like up-to-date Chrome, so plz make it a web app if u care about good things
the difficulty gap between XSS and full RCE is much smaller in Electron compared to a browser like up-to-date Chrome, so plz make it a web app if u care about good things
here's a recent example of XSS -> system RCE in Electron: trustwave.com/Resources/Spid…
Electron has a flag that basically says "allow content to run system commands via Node" and it was possible for a context with that flag disabled to open a new context that had it enabled
Electron has a flag that basically says "allow content to run system commands via Node" and it was possible for a context with that flag disabled to open a new context that had it enabled
at least 3 reasons why XSS -> RCE is easier in Electron vs Chrome:
1. often behind latest Chrome so old 0days will sometimes work (ex: blog.ethereum.org/2017/12/15/sec…)
2. no renderer sandboxing by default
3. privilege boundary b/w content with & without Node access is not well-enforced
1. often behind latest Chrome so old 0days will sometimes work (ex: blog.ethereum.org/2017/12/15/sec…)
2. no renderer sandboxing by default
3. privilege boundary b/w content with & without Node access is not well-enforced
the Electron team knows about these issues and have made some great progress lately. in the meantime, keep in mind that it was designed primarily for Atom, an app that doesn't load remote content.
