From Markdown to remote code execution in Atom
statuscode.ch
From Markdown to remote code execution in Atom
1–10 of 152 posts
Re: From Markdown to remote code execution in Atom
#2> Bringing web security issues to desktop apps
Wonderful :)
Re: From Markdown to remote code execution in Atom
#3Electron 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
Re: From Markdown to remote code execution in Atom
#4Is there a good reason to allow unsafe eval in the Content Security Policy?
Re: From Markdown to remote code execution in Atom
#5Electron 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
See here for the security issues published in Chrome stable releases in those versions:
https://chromereleases.googleblog.com/2017/07/stable-channel... https://chromereleases.googleblog.com/2017/09/stable-channel... https://chromereleases.googleblog.com/2017/10/stable-channel...
Re: From Markdown to remote code execution in Atom
#6Why 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.
Re: From Markdown to remote code execution in Atom
#7Whilst 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?
Re: From Markdown to remote code execution in Atom
#8I'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.
Re: From Markdown to remote code execution in Atom
#9Why 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.
Even whitelisting is dangerous for web/html. Given any tag, there's probably a large number of things you can do with them that boggles the mind as in "whoa I didn't know you could do that..." including things that are not in the w3c specs but are coded into the interpreters.
Basically the experience of a web developer every day, no matter how experienced you are.
Re: From Markdown to remote code execution in Atom
#10This 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.