At QCon New York 2019, Kate Sills, a software engineer at Agoric, discussed some of the security challenges in building composable smart contract components with JavaScript. Two emerging TC39 JavaScript proposals, realms and Secure ECMAScript (SES), were presented as solutions to security risks with the npm installation process.
Today, when running the npm install command, a module and all of its dependencies have access to many native operations including file system and network access. The main security risk is that a rogue dependency of an otherwise trusted module could get compromised and replaced with logic intended to access private information on a local machine such as a cryptocurrency wallet, and then upload that information to a remote server via an HTTP connection.
TC39, the technical committee responsible for future versions of the JavaScript standard, have two proposals which are currently in stage 2 of their approval. The first, realms, makes it easy to isolate source code, restricting access to compartments in which code lives. The realms proposal solves the problem of limiting access to a sandbox, by restricting access to self, fetch, and other APIs outside the sandbox. Realms have many potential use cases beyond security isolation, including plugins, in-browser code editors, server-side rendering, testing/mocking, and in-browser transpilation. A realms shim is available to leverage the current draft proposal of realms today.
Another potential attack vector is prototype poisoning, where the prototype of an object gets changed unexpectedly. The proposal to fight this attack vector is Secure ECMAScript (SES), currently in stage 1 of the TC39 approval process, which combines Realms with transitive freezing. npm install ses provides access to the SES shim.
Realms and SES successfully lockdown JavaScript, but many applications do need access to APIs like the file system and network. During Sills' talk, she highlighted the principle of least authority to only grant what is needed and no more.
Sills provided an example of a command line todo application which relies on a common dependency in the JavaScript ecosystem to modify the styling of the console. This module requires access to the operating system object, but only to work around a color glitch found on specific operating systems. With SES, it is possible to attenuate access to restrict the availability of the dependency to only access the capabilities on the os object necessary to fix the color glitch.
During the presentation, Sills also highlighted Moddable XS, which has full support for ES2018 as well as support for SES, making it possible to allow users to install applications on IoT devices safely. Other examples of current SES implementations include an Ethereum wallet with all dependencies in an SES environment and the Salesforce locker device.
SES and Realms have a promising future, but there are currently some limitations, performance challenges, and developer ergonomics (e.g., modules today need to get converted to strings) to solve before these proposals become an official part of the JavaScript language.