Forem: Doğa Armangil

Preventing supply-chain attacks to the JavaScript ecosystem

Doğa Armangil — Thu, 24 Oct 2024 22:28:21 +0000

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": {
      "read":  {"allow": [], "deny": []},
      "write": {"allow": [], "deny": []},
      "net":   {"allow": [], "deny": []},
      "env":   {"allow": [], "deny": []},
      "run":   {"allow": [], "deny": []}
    },
    "https://cdn.example/org/module": {
      "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 ∎

Qworum upgrades the Web platform for better application support

Doğa Armangil — Mon, 14 Oct 2024 14:58:29 +0000

The Web was initially conceived as a platform for content rather than applications. Qworum is proof that the Web still isn't a full-featured application platform, and that, despite JavaScript. Qworum aims to change that.

Note that Qworum is not a Web framework but an upgrade to the Web platform itself.

💡 What's missing from the Web platform?

There are several big gaps between what applications need and what the current (non-Qworum) Web provides:

Hyperlinks alone are not suitable for linking between applications, but they are great for linking between content. When application A1 calls application A2, how will A1 continue its execution once the call to A2 has returned? For this reason, in the Qworum world linking between applications is done through scripts rather than plain hyperlinks.
Applications are fundamentally stateful, and content is fundamentally stateless. And that's why using the tab history is problematic for applications, but not for content. When was the last time you navigated to a website, signed in, and then went back one page, only to be asked to sign in once again? Last time this happened to me was on Eventbrite. In the Qworum world, the tab history is disabled so that the UI cannot go out of sync with the application's internal state.
Object-oriented programming adopted to the Web platform is a winner. By structuring web applications and APIs as OOP classes, Qworum is able to support distributed applications, UI-level integrations, modular application frontends, and composable and distributed user dialogs.

⚙️ How is Qworum implemented?

Qworum provides a new browser runtime that is implemented as a browser extension. The Qworum runtime is attached to browser tabs instead of individual web pages as the JavaScript runtime is.

🧑‍💻 Show me the code

Here is a video presentation I've posted today. If you are short on time the first 6 minutes are conveying the gist of it.

🎬 Programming with Qworum

🚀 Time for action

Qworum subscriptions are available to businesses worldwide at very affordable prices.

∎

Qworum upgrades the Web platform with essential application features

Doğa Armangil — Mon, 14 Oct 2024 14:58:28 +0000

Note that Qworum is not a Web framework but an upgrade to the Web platform itself.

💡 What's missing from the Web platform?

There is a big gap between what applications need and what the current (non-Qworum) Web provides:

Hyperlinks alone are not suitable for linking between applications, but they are great for linking between content. When application A1 calls application A2, how will A1 continue its execution once the call to A2 has returned? For this reason, in the Qworum world, the linking between applications is done through scripts rather than plain hyperlinks.
User dialogs are not "first-class citizens" on the baseline Web, yet they are essential for applications. Sending a return address to a dialog as a query parameter (for login, etc) and letting the dialog handle the redirection to the caller at the end is a hack at best, and it doesn't scale. How to keep track of the return address if the dialog calls another dialog? And what if we wish to have a different return address for different error conditions (cancelled by user, etc). These scalability problems are intractable on the baseline Web, yet easily solved on Qworum's Service Web through Qworum scripts.
Applications are fundamentally stateful, and content is fundamentally stateless. And that's why using the tab history is problematic for applications, but not for content. When was the last time you navigated to a website, signed in, and then went back one page, only to be asked to sign in once again? Last time this happened to me was on Eventbrite's website. In the Qworum world, the tab history is disabled so that the UI cannot go out of sync with the application's internal state.

💎 What's in it for me?

On the technical front, Qworum is able to support distributed applications, UI-level integrations, modular application frontends, and composable and distributed user dialogs.

On the business front, building cohesive IT systems on top of today's fragmented IT landscape consisting of multiple internal applications, partner applications, SaaS and micro-SaaS is a problem that is largely unsolved. As a result, the employee UX is fragmented across multiple applications. Qworum solves this problem, regardless of the degree of fragmentation of the underlying IT landscape.

⚙️ How is Qworum implemented?

Qworum provides a new browser runtime that is implemented as a browser extension. The Qworum runtime is attached to browser tabs instead of individual web pages as the JavaScript runtime is.

🧑‍💻 Show me a demo, and show me the code

Here is a video presentation I've posted today. If you are short on time the first 6 minutes are conveying the gist of it.

🎬 Programming with Qworum

🚀 Time for action

Qworum subscriptions are available to businesses worldwide at very affordable prices.

∎

Interactive Microservices as an Alternative to Micro Front-Ends

Doğa Armangil — Wed, 08 Mar 2023 12:48:16 +0000

[TRENDING ON INFOQ]

❝Interactive Microservices as an Alternative to Micro Front-Ends for Modularizing the UI Layer❞

As you may know, the rate of adoption for micro front-ends have been tepid so far, and as a result monolithic frontends remain a significant impediment for microservices architectures. Qworum is a solution to this issue which plagues large-scale software systems.

Qworum is a frontend PaaS that brings all the benefits of microservices to the UI layer, and makes web UIs fully compatible with microservices architectures.

Qworum is pioneering several industry-firsts:

a new type of microservice (the interactive microservice),
a new type of web API (the multi-phase web API),
a platform for distributed web applications,
a new type of web (Qworum’s Service Web is about interlinked microservices, whereas the World Wide Web and the Semantic Web are about interlinked content).

Qworum’s “everything is a microservice, including applications” UI paradigm and the “micro frontends plus container applications” UI paradigm