Preventing supply-chain attacks to the JavaScript ecosystem

Supply-chain attacks are big problem for the JavaScript ecosystem. In this short post I will outline a straightforward security measure that can be implemented by all JavaScript runtimes, both in-browser and off-browser. This will prevent most of the supply-chain attacks that are plaguing the JavaScript ecosystem today.

Problem: Permission inheritance

Here's a recent incident where websites were hacked:

• Researchers link Polyfill supply chain attack to huge network of copycat gambling sites

The core of the problem is that JavaScript modules inherit the permissions of the application or module that has called them. This is a problem for both in-browser runtimes and off-browser runtimes.

This problem is further complicated by the fact that the module version that an application depends on can change unbeknownst to the application's author. So even if the codes of all dependencies have been thoroughly reviewed (which is a huge effort in itself), this effort will be wasted if dependency versions haven't been locked down.

Why not lock down versions and use semver-based dependencies? Well, this is mainly because if a module publisher publishes bug-fixes, it's better to use the fixed code. And this is one big reason why JavaScript CDNs such as esm.sh are supporting semvers.

💥 How websites are impacted

Web browsers are sandboxed execution environments, so a third-party JavaScript module (3JM) that's imported by a website can't cause any damage to the end-user's device.

Nevertheless, a 3JM can use the device's compute resources and issue network requests for Bitcoin mining etc, without the website's consent.

💥 How off-browser JavaScript applications are impacted

Some off-browser runtimes such as Deno do implement measures to restrict the permissions given to a JavaScript/TypeScript application. But these measures fall short for the following reasons:

• Even if a permission system such as Deno's is enforced, they nevertheless allow JS modules to inherit the caller's permissions without restrictions. This means that if an application has full write permissions, then an email address validator that shouldn't have access to any resources except compute resources can delete user files unbeknownst to the OS user.
• Applications often run with the full privileges of the OS user. For example, for code executed under a tool such MDRB it's currently not possible to restrict permissions to the code that's running.

The current solution

Currently, security teams have put automated processes in place for looking for vulnerabilities in modules that are published on well-known registries such as NPM. This security measure has several shortcomings:

• Scanning all versions of all known modules that were published is incredibly resource-intensive.
• There's no guarantee that all modules that are available in the wild have been scanned.

💡 Solution: Per-module permissions

To fix these issues, I propose a new per-module permissions system that is backwards-compatible with how JS/TS applications currently work.

This involves a new optional permissions configuration that each application and module can declare in their deno.json / deno.jsonc / package.json files. permissions has 2 parts:

• permissions.self — This is where the application or module declares the permissions that it and its dependencies require.
• permissions.imports — This is where the application or module declares the permissions that it agrees to allocate to its dependencies. This is a superset of the permissions that each dependency is allowed to require.

Here's how permissions would be used by the JS/TS runtime:

• When an application or module imports a module M, the runtime checks whether M's permissions.self is within the limits that the importer imposes on M. The import throws an error (e.g. PermissionError) if this is not the case.
• A runtime error is also thrown (e.g. PermissionError) when a module or application tries to do something it isn't permitted to do. This runtime error can be caught and handled without aborting the application.

The value of permissions would be something like this:

{
  "self": {
    "read":  {"allow": [], "deny": []},
    "write": {"allow": [], "deny": []},
    "net":   {"allow": [], "deny": []},
    "env":   {"allow": [], "deny": []},
    "run":   {"allow": [], "deny": []}
  },

  "imports": {
    "jsr:@org/module@1.0.0": {
      "read":  {"allow": [], "deny": []},
      "write": {"allow": [], "deny": []},
      "net":   {"allow": [], "deny": []},
      "env":   {"allow": [], "deny": []},
      "run":   {"allow": [], "deny": []}
    },
    "https://cdn.example/org/module@1.0.0": {
      "read":  {"allow": [], "deny": []},
      "write": {"allow": [], "deny": []},
      "net":   {"allow": [], "deny": []},
      "env":   {"allow": [], "deny": []},
      "run":   {"allow": [], "deny": []}
    },
    "[default]": {
      "read":  {"allow": [], "deny": []},
      "write": {"allow": [], "deny": []},
      "net":   {"allow": [], "deny": []},
      "env":   {"allow": [], "deny": []},
      "run":   {"allow": [], "deny": []}
    }
  }
}

Compared to the current solution, the solution I propose has several advantages:

• Lightweight — Published modules do not need to be scanned.
• Thorough — Permissions are enforced at runtime, so if the right JS/TS engine is used, then even unknown modules cannot fall through the cracks.

This seems very straightforward. No modification is required to the JS/TS languages. And if the permissions configuration is absent, then we fall back to the current situation where the application and its dependency graph all have the permissions that were provided by the command-line arguments ∎