At least the old problems imply old solutions. The user, as shown in the gif above, cannot know that (s)he is on a fake page because the address bar is missing. An easy solution is to include the address prominently displayed.
I’m surprised that Google didn’t see this coming though.
Yeah having the current URL in an address bar could definitely help. It would also be nice to add a previous button and maybe some tabs, a proper history manage… wait.
Personally I simply prefer to open those "apps" directly in my browser (you can even "pin" them). It saves a lot of RAM, you don't have such nasty security issues and most of the features are still there.
I think it's worse in Electron because the JavaScript code runs in a more privileged context. At least, from my brief run-in with using Electron as a developer, it felt like Node.JS strapped to Chromium, in such a way that all JS code was not sandboxed.
The person who wrote this article seems more concern with phishing, but I don't think the RCE was as big of a leap as they think it was.
Electron definitely offers a developer some real foot cannons - of this there is no doubt.
But to be fair, it also offers some great security capabilities, ala Chrome, like Content Security Policies and a seriously solid sandbox that has had untold (wo)man-centuries of work put into keeping it isolated from priveleged contexts.
Yes, you need to be very careful about stepping over the holy line, but this really isn’t that different from the kind of common sense barrier we’ve all learned to maintain between a web server and a browser client. If someone accidentally throws an API key into some browser js, you’re in trouble. This kind of mistake gets made sometimes (even at high levels) but for the most part, any serious developer will know how to enforce a hard line between the server and the client—it’s table stakes.
A simple approach for Electron is to keep the bulk of your application in a browser window with nodeIntegration: false and then set a strict CSP on the root html doc. In this way, most of your code and most of your dependencies will be isolated from the os and the network, and you can carefully whitelist the exceptions. That’s actually pretty damn hard to do yourself in a purely native app.
In short, if you take some time to learn best practices, you can make a pretty damn secure app with Electron. If you can’t be bothered, then yeah, your users will be in real danger, but they’d be in just as much (or more) danger if you made similar mistakes in native code.
I have tried to do a good job building a secure Electron app with EnvKey[1], a tool for managing configuration and secrets with end-to-end encryption. All the client-side code is open source[2] and has its security choices documented[3]. Feel free to take a peek if you’re interested in seeing a live example!
Oh, and since one’s perfect, please post an issue or a PR if you spot any problems. I will owe you a beer :)
I don't recall ever writing that I'm against using C. I wouldn't go for C in many situations since go and rust are available, but it's certainly the right tool for plenty of jobs.
19 comments
[ 3.3 ms ] story [ 21.5 ms ] threadIt is stories like this that kind of make me more of a curmudgeon, though. I feel like we are just finding new ways to retread old problems.
I’m surprised that Google didn’t see this coming though.
Personally I simply prefer to open those "apps" directly in my browser (you can even "pin" them). It saves a lot of RAM, you don't have such nasty security issues and most of the features are still there.
The person who wrote this article seems more concern with phishing, but I don't think the RCE was as big of a leap as they think it was.
I've been seeing it everywhere after the Trump campaign, and after the 100th time I saw it, it started making me want to vomit.
But to be fair, it also offers some great security capabilities, ala Chrome, like Content Security Policies and a seriously solid sandbox that has had untold (wo)man-centuries of work put into keeping it isolated from priveleged contexts.
Yes, you need to be very careful about stepping over the holy line, but this really isn’t that different from the kind of common sense barrier we’ve all learned to maintain between a web server and a browser client. If someone accidentally throws an API key into some browser js, you’re in trouble. This kind of mistake gets made sometimes (even at high levels) but for the most part, any serious developer will know how to enforce a hard line between the server and the client—it’s table stakes.
A simple approach for Electron is to keep the bulk of your application in a browser window with nodeIntegration: false and then set a strict CSP on the root html doc. In this way, most of your code and most of your dependencies will be isolated from the os and the network, and you can carefully whitelist the exceptions. That’s actually pretty damn hard to do yourself in a purely native app.
In short, if you take some time to learn best practices, you can make a pretty damn secure app with Electron. If you can’t be bothered, then yeah, your users will be in real danger, but they’d be in just as much (or more) danger if you made similar mistakes in native code.
I have tried to do a good job building a secure Electron app with EnvKey[1], a tool for managing configuration and secrets with end-to-end encryption. All the client-side code is open source[2] and has its security choices documented[3]. Feel free to take a peek if you’re interested in seeing a live example!
Oh, and since one’s perfect, please post an issue or a PR if you spot any problems. I will owe you a beer :)
1 - https://www.envkey.com
2 - https://github.com/envkey/envkey-app
3 - https://security.envkey.com
Why then are you here defending Electron despite a similar foot gun that can only be avoided by "being good", much like C?
Seems contradictory to me.