Csdrhrt

The browser isolates JavaScript, as it executes within a browser process itself. It cannot do anything which is not permitted by the browser JavaScript interpreter or JIT compiler. However, owing to its complexity, it's not at all uncommon for vulnerabilities to be found that allow JavaScript to compromise the browser and gain arbitrary code execution with the privileges of the browser process.

Because these types of security bugs are so common, many browsers will implement a sandbox. This is a protection mechanism that attempts to isolate a compromised browser process and prevent it from causing further harm. The way the sandbox works depends on the browser. Firefox has very limited sandboxing, whereas Chrome and Edge have significant sandboxing. However, despite this defense in depth, browser vulnerabilities can often be combined with sandbox escape vulnerabilities.

How is it safe?

It is not. Or more exactly it is as safe as the browser implementation is. Browsers (including their JavaScript engine) are complex pieces of software, with regular addition of new features - because users want them.

That means that, even if well-known ones certainly have quality procedure to test their code against known vulnerabilities, the risk of an undetected flaw in implementing a feature always exists.

Currently, the accepted way is that as soon as a breach is detected, a new version containing a fix is released. But between the discovery of the breach and the installation of the fix, the browser is vulnerable.That is the reason why it is recommended to keep one's browser up to date, in order to only be exposed to zero-day vulnerabilities.

It's true that at the JavaScript level the browsers are designed to sandbox the code under execution (primarily by not exposing any dangerous API), but JavaScript is a very complex language to parse and execute.

ECMAScript is the standard behind JavaScript, due to the huge marketing inflation around beginner-friendly programming languages we are experiencing today, the ECMAScript is updating fast and introducing more and more complex functionality to implement for a runtime.
This, in turn, widen the surface of attack and allow bugs to creep in.

A wonderful example is the recent work of Patrick Biernat, Markus Gaasedelen, Amy Burnett for the pwn2own 2018.

http://blog.ret2.io/2018/06/05/pwn2own-2018-exploit-development/

The blog describe the discovery of a 0day that allows arbitrary code execution in WebKit and how that's used to exploit another 0day in the macOS Window Manager to escape the sanbox Safari is running in (that's a macOS sandbox, not a Safari's one) to escalate to "root" and own the system.

Long story short, by simply visiting a link while having JavaScript enabled, a macOS system can be totally compromised without a single glitch visible to the user.

That's how safe JavaScript can be: As safe as a complex piece of software as WebKit's JSCore can be.

That's why users that require high security are advised to disable JavaScript (that's a fairly common requirement in the DarkWeb, for example).

The vulnerability in WebKit discovered by the authors above is a race condition between the newly introduced garbage collector and the array.reverse function: if the GC starts marking an array while it is being reversed it could lead to a UAF (User After Free) exploit.
The mark is done sequentially on the array, suppose the GC is right at the middle of the array when this is reversed, then second half is never marked and thus elected for collection, resulting in a UAF (the array object itself is not collected, only its element).

How an UAF is used to make more powerful exploit primitives that can lead to arbitrary code execution is more or less a variation of the same techniques: first an interesting object is allocated in the newly freed space (e.g. an array) then a RW primitive is created (e.g. by altering the boundary of the array) and finally arbitrary opcodes are written in memory (e.g in a JITted page).

The details for this particular 0day are in the linked blog.

The interesting part is the way this 0day was found: since WebKit is so big an in depth code review is impossible without an huge amount of effort so and automated jitter was set up.

This must make us reflect on the fact that when we have hundred thousand or millions of lines of code, it's very hard to make each one behave nicely with respect to every other one.

As stated in other answers, each browser has its own script engine that is designed to sandbox JavaScript execution and each engine attempts to limit JavaScript functionality that could lead to malicious behavior.

But as a rule JavaScript has never been safe within the browser. Malicious code developers are constantly finding ways to exploit how each engine works as well as its available JavaScript functionality to achieve malicious goals.

In the first few years, JavaScript was rather dangerous within the browser. Now it is a constant race between malicious code developers and the browser/engine developers and eventually the malicious developers always win, even if just for a short time. So JavaScript can hardly be called safe. "Should be safe for now" is a more accurate way to put it.

JavaScript is pretty powerful

It is which is why many users consider it unsafe and block it using browser extensions. JavaScript allows websites to track users in ways not possible without it including identifying users after they have deleted their cookies by fingerprinting the browser. Many of the newer web APIs like WebUSB allow things that are not at all safe but browsers will request user permission when accessing unsafe APIs like USB and camera.

It is safe compared to machine-level executable code, like ActiveX uses.

A machine code program has unmitigated access to any interface the operating system and libraries provide to any program running under that user account, is only REALLY restricted in what it can do by what the hardware and operating system restrict it to - essentially making such a program as powerful as the user running it. There might be tools that try and restrict it by intercepting some of the interfaces provided, but it is hard to stop a program aware of such measures to circumvent them.

The javascript interpreter is part of the browser, and written in a way that it only offers the program it is running the interfaces and powers it wants to offer them.

JavaScript is "relatively safe," but not "absolutely safe." Any code you run on your system has a potential to do harm. There is no perfectly safe system, except for the one that never used. JavaScript is safer than putting an unknown USB device in your computer, and safer than a binary you download from a shady website or get in a suspect email attachment, and much safer than some of the scripts you'll find on websites that tell you to copy-paste them in to your shell.

It has safety features: a sandbox to help isolate the process, a relatively limited API that has security constraints to help avoid running arbitrary computer instructions, and security controls meant to limit exposure of sensitive data like fingerprints or cross-domain data sharing. These are on top of your operating system's controls applied to the browser binary to limit bad behavior, and anti-virus applications that can help stop such attacks.

However, it is not absolutely safe. Bugs in the browser's runtime engine, the browser itself, the anti-virus, or even the processor itself can all compromise JavaScript's security. The system is only as secure as its weakest security. The security of JavaScript is mostly meant to prevent "casual" exploits (such as an 8-year-old learning JavaScript for the first time and accidentally writing an exploit), but doesn't stand a chance against dedicated attackers. JavaScript is complicated enough that there are bound to be bugs, perhaps in weird and unexpected ways.

Those experienced in hacking, pen testing, and security can, and do, browse through source code, debug executables, and do whatever else they can to try and find chinks in the armor. The weak points of the JavaScript implementation. And JavaScript is big enough that such chinks exist to begin with, since it is virtually impossible to even automate all the possible tests that would find these bugs.

Generally speaking, any typical script you might run in to on a typical website is probably "safe", especially those linked to by major search engines. However, once you start going off the beaten path, it is incredibly likely you'll get your system compromised at some point if there's even a single weak point. It only takes one really good exploit, or sometimes two or three in tandem, to completely take over a system.

As it is, only enable JavaScript for sites you trust (I personally use NoScript for this purpose), always keep all your software up to date, and always pay attention to browser warnings like invalid certificates and so on. Even then, you won't be 100% safe, but you'll be taking an active part in your own mitigation strategy.

There is nothing inherently safe about JavaScript, in many ways it is less safe than other languages:

• eval statement


• dynamic typing

It is the sandbox where the browser executes the JavaScript that provides the safety. See documentation on the Chrome sandbox here, notice there is no reference to JavaScript or ECMA script.

Today, the great majority of code executing in the browser is written in JavaScript. With the rise of WebAssembly, we will likely see the browser platform switch from the primarily single language lock in of today (like a mainframe of the past) to an open platform where any WebAssembly compliant language can be used. This will, in a way, prove that JavaScript isn't particularly safe/special, as at that point many languages will be executing in the browser. All of these languages will use the sandbox provided by the browser to execute.

This answer will address two points raised at the question and one browser "feature" not raised in the question.

JavaScript has certain limitations such as preventing reading and
writing to disk

such limitation does not technically exist at Chromium/Chrome browsers where requestFileSystem is defined, which writes directly to disk; that is, the File System folder of the Chromium/Chrome configuration directory at the users' file system.

See How to Write in file (user directory) using JavaScript?

and not allowing access to other browser windows or domains.

If a window is opened from an already opened window, communication between windows is possible using, including, but not limited to, postMessage, MessageChannel, SharedWorker, or simply query string parameters.

See How can I load a shared web worker with a user-script?

One other point not mentioned at the OP that must be raised here specific to Chromium/Chrome is the fact that the SpeechRecognition implementation of Web Speech API at those browsers records the users' voice (biometric identifier) and sends that recording to a remote service, without directly advising the user that is what is taking place. It is not immediately clear if the recording(s) are retained (forever) by the undisclosed "web service" or "deleted" at some point.

See Does webkitSpeechRecognition send recorded audio to a remote web service by default?