1. Why don't browsers execute (interpret?) languages other than JavaScript?
I believe the general idea was that they would, because the "type" attribute in the <script> tag didn't need to be "text/javascript", but javascript happened to win because it was supported by Netscape Navigator. Microsoft had VBScript, but that was an IE only product, while both browsers supported javascript, making it the only choice for cross-browser compatible scripting (albeit with lots of irritating hacks, but then jQuery came along.)
See this decent StackExchange thread here[0].
Then HTML5 deprecated the type attribute from the script tag because there really was no point anymore. Why support other languages when one language was adequate and already ubiquitous?
2. What would be involved in having a browser execute (interpret?) other languages, such as Perl or Python?
Today? Browsers could ship with support for those languages (the way Chrome did with Dart) but of course, that would fragment the web unless all browsers supported all options. Or maybe plugins. Or "compiling to javascript." Or Webassembly[1].
I 100% believe that seamless, dynamic language support through WASM is going to be a thing eventually.
It'll be interesting to see how this works, given that the Signal Desktop client's main page (background.html) includes a CSP that restricts it from running inline or external scripts. It can only run JS that's already in the Signal Desktop package (in theory).
The fact that this isn't being described as an issue with CSPs or electron makes me wonder how it could possibly work.
You are correct, there's also a flaw on CSP not limiting all the ways you can download a resource. And at this time, it's still not fixed. We'll publish an advisory soon.
You've linked that thread a couple of times here, never really elaborating on the nature of your concerns, nor do you elaborate on the specific nature of your concerns in the ticket. Have you considered elaborating on the nature of your concerns? Is there a specific vulnerability in chromium you feel could be exploited here?
It's time to admit that we can't fix web security anymore, and that we should just start anew. XSS, SQLi, cross origin flaws, etc. There are just too many vectors for a human developer to make a correct implementation.
It's time to admit that we can't fix web security anymore
It seems like this was fixed in a newer version of chromium.. a version that electron is not based on. This particular problem exists purely because they used a framework that depends on a ridiculously complicated backend, one that the framework has chosen not to follow closely (despite the backend addressing security issues relatively timely)
Ah, yes, Electron, where a simple XSS can quickly turn into full account compromise and RCE? :O
https://blog.doyensec.com/2017/08/03/electron-framework-secu...
Alas, if only there were a way to write native applications in some language other than javascript...
Why would you want to do that? JavaScript is memory-safe.
Other languages? Doesn't JavaScript solve all use cases in every possible context? ...
Serious questions:
1. Why don't browsers execute (interpret?) languages other than JavaScript?
2. What would be involved in having a browser execute (interpret?) other languages, such as Perl or Python?
I believe the general idea was that they would, because the "type" attribute in the <script> tag didn't need to be "text/javascript", but javascript happened to win because it was supported by Netscape Navigator. Microsoft had VBScript, but that was an IE only product, while both browsers supported javascript, making it the only choice for cross-browser compatible scripting (albeit with lots of irritating hacks, but then jQuery came along.)
See this decent StackExchange thread here[0].
Then HTML5 deprecated the type attribute from the script tag because there really was no point anymore. Why support other languages when one language was adequate and already ubiquitous?
Today? Browsers could ship with support for those languages (the way Chrome did with Dart) but of course, that would fragment the web unless all browsers supported all options. Or maybe plugins. Or "compiling to javascript." Or Webassembly[1].
I 100% believe that seamless, dynamic language support through WASM is going to be a thing eventually.
[0]https://softwareengineering.stackexchange.com/questions/2894...
[1]https://github.com/mbasso/awesome-wasm#languages
Chrome never shipped Dart support. There was a modified version of Chromium with Dart support called Dartium, but it was discontinued with Dart 2.x.
There's a plugin to run TCL in the browser [0]. Last update appears to be 2006 though, so I doubt it's usable on today's browsers.
There was an effort at one time to implement a Dart VM in Chrome [1]. That has been stopped, though [2].
[0] https://www.tcl.tk/software/plugin/
[1] http://googlecode.blogspot.com/2011/10/dart-language-for-str...
[2] https://news.dartlang.org/2015/03/dart-for-entire-web.html
It'll be interesting to see how this works, given that the Signal Desktop client's main page (background.html) includes a CSP that restricts it from running inline or external scripts. It can only run JS that's already in the Signal Desktop package (in theory).
The fact that this isn't being described as an issue with CSPs or electron makes me wonder how it could possibly work.
You are correct, there's also a flaw on CSP not limiting all the ways you can download a resource. And at this time, it's still not fixed. We'll publish an advisory soon.
In Electron, all file:/// URIs share an origin. Using `script-src: 'self'` isn't much of a boundary.
So let's say I'm able to run HTML in Signal Desktop. How do I include an arbitrary script without getting the user to download the script first?
If I remember correctly, on Windows you can reference file://<IP-Address>/path/to/file
Thanks SMB / UNC Paths.
For reference: https://github.com/electron/electron/issues/5151
Electron is unsafe because it's based on outdated versions of Chromium: https://github.com/signalapp/Signal-Desktop/issues/1635
You've linked that thread a couple of times here, never really elaborating on the nature of your concerns, nor do you elaborate on the specific nature of your concerns in the ticket. Have you considered elaborating on the nature of your concerns? Is there a specific vulnerability in chromium you feel could be exploited here?
Signal desktop app is based on the insecure Electron runtime. See my report here: https://github.com/signalapp/Signal-Desktop/issues/1635
I read the (now locked) thread, the way they handled the report leaves much to be desired.
It's time to admit that we can't fix web security anymore, and that we should just start anew. XSS, SQLi, cross origin flaws, etc. There are just too many vectors for a human developer to make a correct implementation.
It seems like this was fixed in a newer version of chromium.. a version that electron is not based on. This particular problem exists purely because they used a framework that depends on a ridiculously complicated backend, one that the framework has chosen not to follow closely (despite the backend addressing security issues relatively timely)