This is really cool, but executing other people's javascript in a page makes me nervous. What sort of restrictions are in place to prevent malicious exploits?
Somewhat off topic, but how do single page apps deal with people hacking the JS? For example, if as a particular user I am only allowed to perform certain functions within the app, and that functionality is contained in the JS, then it doesn't seem like it would be very hard to modify the JS to enable the functionality I shoudn't be allowed to use.
Honest question, which part of writing it in JS makes it less safe? I understand that running in a browser is an inherently unsafe model because of the various mechanisms that make it impossible to track code that's running along side yours. How is it that JS is unsafe in a server environment?
You probably don't run arbitrary untrusted applications on your computer but you execute arbitrary untrusted Javascript all day when visiting web sites. To make this seemingly crazy thing work at all, some restrictions have to be imposed on that untrusted JS code.
FYI malicious JS executing in victim users' browsers is a huge concern. All sorts of vulnerabilities can be exploited via JS in this way -- every local side-channel like Spectre/Meltdown, worse things like Row Hammer, etc.
I wish there was a way for page authors to disable user scripts.
Yes, I realize that users can easily open up a console. I'm not afraid of the users, I'm afraid of roque JavaScript being injected into a page that's reading sensitive data and using it for nefarious purposes.
Why? This seems like an irrational fear, it’s not specific to JavaScript in any way. All code is subject to those exploits. Anything you run in any language.
> Typical worrisome cases are when a malicious script scrapes credential forms or the tracking of mouse cursor movements / page scrolling for advertising analytics.
You do realize that the only way JavaScript runs on a page is for the remote site to choose to include it, right? If you don't trust their JavaScript why would you ever put sensitive information in a form and submit it anyway?
AU CONTRAIRE, javascript being unsafe would be the first of my worries. what's the point of all that anonymizing software when a tiny bit of js hackery undoes it all?
I feel like there are a lot of CVE's in the JS community that basically require an attacker to already have access to server side code execution. That seems like it raises some bigger questions.
Not wanting to execute arbitrary untrusted code on your machine? While there has been lots of good work put into sandboxing browser by the browser vendors, the ability for attackers to run custom code within the browser makes many exploitable vulnerabilities a lot easier to exploit. Things like the various privacy leaks based on cache timing, visited link styles, and so on, or just exploiting buffer overruns that have been protected against by address space layout randomization but with arbitrary code the exploit can try the same thing over and over again with different size inputs until it finds one that works.
Running JavaScript in your browser automatically from any site that you visit is pretty darn scary when you think about it. You can protect from a whole host of vulnerabilities by disabling it, and then whitelisting only hosts which you trust.
Hey Joe, the idea of the plugin is to lock the page against users that don't have programming skills, since JavaScript is a client side language, there is no way to protect 100% against this changes.
If there is no vulnerability in the javascript engine or any of the API they exposed to it in order to mockup a web browser then it can't do anything. The problem here is that that's not exactly a tiny attack surface, and modern web browsers implement defense in depth and sandboxing untrusted code for very good reasons. If there was some RCE for a part of this javascript engine, you're not just executing inside of some locked down environment, you're not just executing code as an untrusted user, you're executing code in a process with SYSTEM level permissions.
This is like putting a 2 meter wide thermal exhaust port on your death star. On the off chance someone manages to hit it, game over. This process runs untrusted code so if you can get a file opened on the target computer, or even just get the user to go to a malicious website, you can try to attack this. Once you get some payload running yeah you could use bog standard crimeware to sniff out any credit card details entered, export your saved passwords from your web browser, look for any wallet.dat equivalents and run a keylogger waiting for you to decrypt it, drop some ransomware on the system, etc. This gives full control over the system if you find an exploit to it.
But yeah, this isn't immediately a vulnerability, just a poor design decision and a very juicy target.
reply