As soon as I saw the title I suspected the exploit was probably markdown related, as I had fixed pretty much the exact same issues in VS Code. Two things to keep in mind when developing electron apps:

- The potential impact of an XSS or other security exploits is much higher. You can limit the impact of most of these with additional layers of security, such as running untrusted html in isolated environments with node integration disabled. However, also remember that...

- Many security features are opt-in. Content security policies (CSP) are a good example. Pages without a CPS default to allowing anything, which sort of makes sense in browser world for backwards compatibility, but is not a good idea for desktop apps.

I've an idea. Let's write GUI apps using GUI libraries, like everyone used to, instead of writing them for a web browser.

Not only will this be more secure, it'll also be 10s or 100s of times more performant.

I wish there was a dead-simple, you-cannot-get-it-wrong, step-by-step, nothing-left-out, no-knowledge-assumed, all-in-one-document, not-spread-out-over-various-pages, tutorial/checklist on how to ensure your Electron app is as secure as possible.

It shits me that it is a research task with all the attendant uncertainty about whether or not I did in fact make it secure.

I do appreciate that security is complex and even such a document would not guarantee security, or that you had not somehow created your own security hole, but I just want to do the very best possible effort at security and currently that is too hard with Electron.

UPDATE: this post has led me to attempt to redesign my application to not use Electron. I just can't afford some misconfiguration or coding error leading to user machines being cracked.

Electron makes things worse: it is not secure. Electron has many security vulnerabilities. The latest version is still based on old Chromium (58 & 59) so it inherits many of the security vulnerabilities published in Chromium 60, 61 and 62

Whilst it's very hard to write a secure C application because writing C is hard, it seems it's very hard to write a secure application in javascript because javascript is too easy. Maybe we should stop blaming language complexity and start blaming the complexity (or lack thereof) of the designs that fail us?

This is why I don't run any Electron apps on my computers at all, ever.

That means I'm stuck with the web browser version of Slack, Skype, Signal (going away), and so forth, which is a shame. But it's better than the security nightmare that is Electron.

I wish developers wanting to make cross platform GUI applications would look instead at Qt. It's extremely easy to use, really fast, and generates great GUIs. It's been around for ages and continually sees updates. Usually people who see the Qt light are pretty satisfied. It can also be used from a wide variety of languages, in case you're not into writing C++.

I sort of suspect that Electron's popularity is due to it being accessible to the hordes of JavaScript developers who otherwise wouldn't have had any clue how to make desktop/native applications. However, do I really want to be running unsandboxed xss==>rce code written by clueless devs? No, no I do not. So, in the end, refusing to run Electron apps turns out to be a somewhat reasonable security posture.

> Bringing web security issues to desktop apps

Wonderful :)

Why does anyone think that blacklisting things they know about makes html more secure?

I guess whitelisting only the things they are absolutely sure are harmless is way more work.

Is there a good reason to allow unsafe eval in the Content Security Policy?

This is horrifying. And they only applied a bandage as a fix.

Unrelated: the article kept sending blurry low-res images and downloading the full version as I scrolled past them. I found this very annoying since I have a poor internet connection and had to wait for each image to load. I’d much rather prefer a slightly longer initial page load than waiting for each image.

The author suggests a malicious attacker might typosquat common packages and embed the exploit in a readme.

But if the user is already downloading your package, why bother with an exploit? You’ve got all the permissions allocated to packages (which I imagine are most permissions). You can just execute the malicious code directly from the package.

Edit: nvm

Neither of those is about "hard" versus "easy". C pre-dates a modern understanding of security boundaries and tries a little bit too hard to be "close to the machine" (so long as the machine looks a lot like a PDP-11). Javascript-the-language is not the problem, but having the whole browser infrastructure present in order to render a document is the problem here in Electron.

The challenge in language design is to erect the right number of boundaries and barriers, in the right places. Too many, and you get people complaining that they can't write Rust because of the borrow checker. Too few, and you get people vaporising multi-million-dollar Etherum contracts by mistake.

C isn't hard. C is easy, in fact. This is the main impetus behind its popularity: people liked it, in part because it was easy. Security is hard in c, in part because c tries to make things easy for the developer at the detriment if security. Javascript is in the exact same posistion. Why is javascript popular? Because its easy. Why is javascript easy? Because none of its features are focused on security.

Look, I love Qt; I worked with it a ton, I contributed back to it, I even still work on LXQt sometimes.

But the rise of web apps, and Electron along with it, have turned the Linux desktop from a "you need to dual boot or use wine" machine into one where all my tools and apps are Linux compatible and have feature parity with Windows and macOS.

I also wish Qt would see more use, I also wish more people would write desktop apps using desktop frameworks when it's meant to be a desktop app, and I really wish people would start writing tiny CLI apps in nodejs and include 70 dependencies. But truth be told, I'm happy to live in a world where I can do 100% of what I do on Linux without feeling like a second class citizen.

I think the "Web on desktop" paradigm is the future, even if it's currently a bleak one. Ten years ago, it was becoming pretty clear that Javascript would be the future, and at the time that was a bleak prospect -- but tooling improved and today, things like Typescript, React, the plethora of incredible development tooling and excellent cross-platform compatibility have turned what used to be bleak into an excellent environment.

There's a lot of improvements that can happen with Electron, if rather than fight it we actually embrace it. Running 10 different web browser engines for 10 different apps may be silly, but what if Electron was global to the desktop instead of included in every fat app?

You'll note that Google has been dipping their toe in that water for years with ChromeOS; Mozilla also tried their version of it with FirefoxOS, which failed for a plethora of reasons that don't undermine the concept at its core.

Basically, JS on the desktop is in the same uncanny valley as it was on the web a decade ago. It's ugly, slow, overwhelming and changing too fast. But there's an end goal there, which doesn't have to suck.

All your positives about Qt can be applied to electron but even better. From a business point of view electron is a winner. For example at our company we have built a desktop app, web app, salesforce plugin, chrome extension, outlook plugin, cli app, and are working on mobile apps all using one JavaScript codebase. It’s a business and developers dream.

There really is no competition and any claim to the contrary would need to offer more than a cross platform desktop app.

> I sort of suspect that Electron's popularity is due to it being accessible to the hordes of JavaScript developers

Look, let's not kid ourselves, we all hate JavaScript like it's the plague, but no other framework comes even close to the ease of CSS/HTML and a drop of JavaScript for interactivity (transpiled from a sensible language), when it comes to GUI development. It's such a fucking embarrassment working with Gtk, Qt, Tk whatever have you, it's not even funny. Even native mobile dev (Swift/Java) is easier through a web interface, because nobody wants to have to remember that you had to "drag click from here to your source code" or "add this to your xml file to make it accessible".

Honestly, Electron is a shitty resource hog, but it is a trillion miles better than what the current offerings are.

welcome to the history loop!

it is a very known fact for all unix grey beards (insert more inclusive analogy if you can think any) that containers and fat binaries lead to way more code rot than anything else. and consequently more bugs and security bugs.

I blame this fad coming back on apple. linux and even Microsoft were happy with shared libraries, until osx adopted the bait and switch tactics of Microsoft and got the whole industry by playing the "but I am unix" tune. and with it the whole (webdev) industry was back to fat binaries.

then people started to realize they dont have to find out the source code to patch that old application just because they have to patch openssl or something. they can just release an entire image! and they have no idea they will make it even harder to have a legacy build when that other openssl bug hit. but for now, everyone can be agile and live serverless! and users now have to update the OS, the few shared libraries, and every and each one of their fat binary applications and container images!

good luck with that

On what basis do you think a complex c++ app would be more immune to security issues as compared to one written in a higher level language? Witness all the security exploits with Microsoft Word over the years.