
Building a Secure Electron App - bobblywobbles
https://github.com/reZach/secure-electron-template
======
itsananderson
It's a great idea to have a template for writing secure Electron apps, but
this particular template should only be used with caution. I don't think it
has been reviewed or endorsed by the Electron team as actually following those
best practices, and I see a few issues just skimming from my phone:

They're trying to expose IPC to the renderer in an unsafe way. See their
discussion on this GH issue
[https://github.com/electron/electron/issues/21437](https://github.com/electron/electron/issues/21437)
(referenced from the main readme as blocking some features they want to
implement)

On their "building a secure app" page they complain about Electron's quick
release cadence [https://github.com/reZach/secure-electron-
template/blob/mast...](https://github.com/reZach/secure-electron-
template/blob/master/docs/secureapps.md)

> The trouble that I've found with electron, is that their release schedule is
> crazy, with only a few months before each major release. We know that
> electron is a young framework, but it is hard to keep up so quickly!

Electron releases quickly to pull in critical upstream security fixed from
chromium. That reasoning is explained pretty thoroughly in the best practices
documentation [https://electronjs.org/docs/tutorial/security#17-use-a-
curre...](https://electronjs.org/docs/tutorial/security#17-use-a-current-
version-of-electron)

I haven't looked at their implementations of the other security best
practices, so these might be the only red flags, but I'd still recommend
against just blindly copying the template without understanding and verifying
the best practices they're attempting to implement.

~~~
bobblywobbles
(author)

Thank you for your feedback. This template has not yet been reviewed but I
hope to get candid feedback like yours on spots that may have been missed.

I am planning to change the way the IPC renderer is exposed; Marshall from the
Electron team pointed me to a better way of doing so and I hadn't had time to
update the repo yet. That will be something I update soon in the code and in
the docs.

The best practices I take from Electron themselves;
[https://electronjs.org/docs/tutorial/security](https://electronjs.org/docs/tutorial/security).
If there are other security reports please send them to me and the template
can be enhanced further.

~~~
yodon
Is it possible for you to switch your license to something more like MIT or
BSD? The work you're doing is great but I believe the majority of Electron
apps are developed inside companies and by licensing your project as GPL you
make your work into something most commercially employed devs can't touch.

~~~
extra88
Looks like they just switched to the MIT license (same license Electron itself
uses).

------
pspeter3
I wish that Safari would support Progressive Web Apps on Desktop like Chrome.
I would much rather provide an Application Manifest and Service Worker than
building a pseudo native desktop app.

------
kilian
This is based on the Security documentation that the Electron team maintains,
which is full of good advice:
[https://electronjs.org/docs/tutorial/security](https://electronjs.org/docs/tutorial/security)

------
moloch
If anyone is interested in Electron application security, I wrote a guide that
explains the methodology behind some of the choices the author here has taken
and even goes a bit further in a variety of areas:
[https://know.bishopfox.com/research/reasonably-secure-
electr...](https://know.bishopfox.com/research/reasonably-secure-electron)

~~~
bobblywobbles
(author)

Thank you, I will read up on this!

------
sansnomme
For other types of security try [https://github.com/tauri-
apps/tauri](https://github.com/tauri-apps/tauri)

It is an electron-like framework written in Rust, and is designed to be as
lightweight as possible.

------
yodon
Be aware this is GPL licensed

~~~
bananabreakfast
What's wrong with free software?

~~~
tptacek
Nothing, but a GPL-licensed framework is one that is difficult to use
commercially, because this is a case where GPL "infects" the user. This use
case was the reason for creating the LGPL.

------
cfv
Is it still possible to unpack the asar, rewrite the source, and repackage the
asar?

~~~
bobblywobbles
(author)

Yes, it is quite possible to do that. One of my down the road goals is to add
light obfuscation to the source code upon packaging. If anyone is motivated,
they can break into _any_ source code and repackage.

I'd also like to add some form of checksumming, but again if they have access
to the source code they can change anything they want to.

~~~
jimbobimbo
Code signing with a trusted cert is what really helps in this scenario.

~~~
cjbprime
It's tough due to platform limitations -- e.g. I think that macOS codesigning
will only sign binaries, and your JS/ASAR files are not binaries.

~~~
jimbobimbo
Shouldn't Electron be a "platform" in this case, and provide affordances for
that?

~~~
cjbprime
It is better to use OS codesigning than hand-built codesigning because then
the OS can enforce it -- e.g. App A can't overwrite App B. Anything you hand-
roll can be unrolled by an attacker.

I guess my preferred solution for be for Electron to find a way to put the
ASAR inside the main binary and find it there and then codesign that, I'm not
sure why it hasn't happened yet AFAIK.

~~~
jimbobimbo
It depends what the threat model is. My understanding of Electron apps is that
the binary part of the app (Chromium, node, whatever are the parts of the
Electron that present the app to the user) is not changing all that often,
while web app bits can be updated by simply downloading new version from the
publisher's site (correct me if I'm off base here). If this is the case, then
the threat here would be the attacker MITM'ing communications between the user
and publisher's site and serving malicious payload to the user. Electron
validating the signature before serving downloaded bits would mitigate the
threat even without OS support (remember - Electron haven't changed, only web
app bits have).

Note that I'm saying "Electron validating the signature" \- not web app doing
that, which I assume what you meant by "hand-rolling".

------
cjbprime
It would be cool to have a regression testsuite showing "insecure" code for
each class of security problem, and showing that the problem is fixed by the
template.

~~~
bobblywobbles
(author)

That's on my roadmap! Do you have ideas on how a testsuite for that might
work? I am open to suggestions.

------
bilekas
> Secure Electron App Bit of an oxymoron no ?

/facetiousness

On a lighter note :

> Feature #1

> Only load secure content - (Need help!)

What kind of help? For this template project ?!

~~~
bobblywobbles
(author)

Yes, I need help as I wasn't able to test the security recommendation. I found
some snippets but they didn't work when I tested locally.

