The big problem with Electron isn't that it forces you to keep up with Chrome, although that's important too, but rather that it links Node.js with content-controlled Javascript, so that DOM corruption vulnerabilities can be leveraged for RCE, even in the absence of a Chrome vulnerability. Most Electron RCEs that you've read about had nothing to do with Chromium.
There's a whole process for evaluating and auditing Electron applications, which is harder to do than auditing (for instance) a native mobile application or, probably, even a native desktop application.
> rather that it links Node.js with content-controlled Javascript, so that DOM corruption vulnerabilities can be leveraged for RCE, even in the absence of a Chrome vulnerability
Can you explain this further? How is it different than a web-app with a NodeJS backend?
Imagine you’re writing Javascript code on a webpage. You write `const fs = require(‘fs’)`. It throws an error because the browser has no idea what “require” or “fs” are.
In electron, you can configure your page to be interlinked with node, so that you could write `const fs = require(‘fs’)` and import the Node filesystem module. This is a big feature of Electron, but it also opens you up to a whole host of vulnerabilities.
For instance, you are never supposed to spin up a WebView like this and then just load random URLs (this is emphasized in the docs when they’re explaining how to do this). However, if you did, untrusted code on a random webpage would have access to the user’s filesystem.
> Under no circumstances should you load and execute remote code with Node.js integration enabled. Instead, use only local files (packaged together with your application) to execute Node.js code. To display remote content, use the <webview> tag or BrowserView, make sure to disable the nodeIntegration and enable contextIsolation
In electron the UI javascript is running in a separate process than the node javascript. They can communicate through Electron's IPC channel.
I wouldn't be too surprised if it could be exploited, but it's not as easy as require('fs'). Instead you have to send messages through the pipe and you'd have to know how to exploit the handlers at the other end in the NodeJs process.
I was on a phone before and didn't have the docs pulled up, but the thing I was referring to is called nodeIntegration (it's a boolean you set in the webPreferences object in the options object you pass to the BrowserWindow constructor).
Why would they need a node process? Are there things an Electron app needs to do that isn’t possible from the Chrome runtime? And more importantly, why would they need to directly link with the DOM?
Well, one very simple example is access to filesystem. You can't do that from Chrome but can from node. In this particular case for example WhatsApp could have a cache of the images and videos attached to a conversation, without having to obey the limits of local databases imposed by PWAs.
The way I author my Electron apps to avoid this is to have a HTTP/Websocket server spin up at a random port, and then use that process to open an Electron window, with Node integration disabled.
This then becomes exactly the same as writing a web app, with anything that cannot be done by the renderer (Ex: file access) being done by the 'server'. Always wondered why this was not an officially strictly recommended way of doing this.
Correct me if I misread. You're leaving ports open on a customer machine, which has its own potential for security issues, even if you bind to localhost.
Wasn't there a Mac app that recently got a lot of flack for this?
Yes that's correct. And AFAIK the consequence was that any browser tab capable of running javascript could make HTTP requests to localhost and access the webcam.
Latency. The electron IPC is way faster than using web sockets and the ability to have node modules in the renderer makes some task actually feasible. I've worked on apps that were quite possible to do with electron but were completely out of question in more classic environments like Cordova or in Android/iOS web views.
Just remember that authentication and origin checking is completely up to the websocket server.
Any random page in a browser can talk to your websocket cross origin, and it's up to your server to check the "Origin" header to make sure it's actually your app on the other end.
Yes and no. Recently browsers started assuming that a response without CORS headers it unsafe unless from the same origin. So even though you can make a request if it fails preflight it will not even reach your server.
You can try this by opening a console on any webpage and trying to do fetch requests or add img tags to the page that are loading resources from localhost.
Or just use unix domain sockets and named pipes, and then you don't have users complaining that you've used some random port that they want to use for some reason.
But really for stuff like file system access just use the node APIs, don't shuffle this stuff through any hand rolled IPC.
Since bridging Node.js with the DOM is basically the whole point of Electron, it's a little tough for me to answer this question. Yes, there are things Electron apps need to do that you can't do from standard Chrome.
That obviously depends on what your Electron app wants to do.
Let's say you're writing an IDE in it. How would you invoke compilers & debuggers, cache filesystem/type information, state, etc. without breaking out of the browser sandbox somehow?
They would be amazed, as this sounds like incredibly advanced technology, and maybe disappointed when they find it was all about imaginary objects in an interactive projector.
There's a whole process for evaluating and auditing Electron applications, which is harder to do than auditing (for instance) a native mobile application or, probably, even a native desktop application.