It’s been a couple of months since my post about the state of security in Electron and a lot has changed in this short time frame already! Now that Electron v1.0 has been released I thought it would be a good time to take another look to see what improvements have been made.

Growth + Maturity

Growth of the Electron framework over time
Image taken from Electron v1.0 release announcement

Electron continues to enjoy enormous growth, with the 1.0 release representing a major milestone in its maturity and stability. Electron’s developer community also continues to grow, with more and more companies building an ever-widening variety of applications using the framework. This is welcoming news, illustrating how Electron is being tried and tested for an ever increasing amount of use cases each with their own security challenges.

Electron’s documentation has also been completely revamped, it’s now a lot cleaner and clearer to read through and understand. API demos have been introduced to help explore the API in a more practical way, and a security tutorial has been written to provide advice, tips and guidelines on securing your application. It’s nice to see official security guidance from the Electron team, demonstrating that it’s something they’re concerned with when developing their framework.

Workarounds Fixed

In my previous post, I discussed two workarounds (3943, 4026) that allowed node integration to be re-enabled despite it being explicitly turned off in the configuration. In the event of a successful XSS attack, it meant the attacker could re-enable node integration to gain full control over the victim’s machine! Since then, changes have been implemented that were released in version 1.1.1 to fix these workarounds.

Firstly, child windows are now prevented from having nodeIntegration if their parent windows do not have it.

// This will now only enable nodeIntegration if the parent window also has it enabled
window.open("www.example.com/evil.html", "", "nodeIntegration=1");

Additionally, webview elements are now disabled in any parent window without node integration:

<!-- webview elements are now disabled if the parent window doesn’t have node integration -->
<webview src="data:text/html,<script>var fs = require('fs')</script>" nodeintegration></webview>

With these fixes, nodeIntegration cannot be re-enabled in the event of an XSS attack. Previously, any XSS attack could re-enable nodeIntegration to gain full control over the victim’s machine, even if it was explicitly turned off in the configuration.

Sandbox

One notable contribution highlighted as an upcoming change in my last post was the re-introduction of the Chromium sandbox for any Electron processes that didn’t need node integration. The developers behind the Brave browser planned to contribute back the sandbox support they implemented on their fork of Electron. However, it seems the changes they made won’t be contributed back after all, since it required extensions that some core contributors weren’t happy including in Electron.

It’s an understandable decision to make but nonetheless a bit of a shame that sandbox support hasn’t been contributed back. Without the sandbox, Electron applications aren’t run inside a restrictive environment that controls what processes can do.

It’s worth mentioning that the benefits to introducing the sandbox are reduced thanks to the node integration workarounds being fixed. Without those fixes, only the sandbox would have prevented XSS attacks from gaining full privileges over a victim’s machine. Adding the sandbox now would mean it serves as an additional robust layer of protection and last line of defence.

Additionally, this doesn’t change the job of securing any Electron processes that did require node integration. The sandbox was only planned to be enabled for processes that didn’t require any integration at all. For applications with node integration, it’s especially important to follow the principle of retaining the least amount of privileges needed to perform their business function, to ensure any successful attacks don’t result in complete control being granted over a victim’s machine.

Conclusion

Only two months have passed and already so much progress has been made towards improving Electron’s security and reliability. All of the security workarounds highlighted in my previous post have been fixed, illustrating the rapid progress being made by the community.

It’s a shame that Brave’s sandbox support hasn’t made it into Electron, giving Electron applications the same sort of protection offered by applications running inside Google Chrome. There’s still hope that this may be something added into the framework in the near future.

I’d consider the Electron framework to be mature and secure enough for the vast majority of applications to be built using it. With the rapid growth and progress of the framework, it won’t be too long before more and more people share my viewpoint!