Single-Use Servers for Web Application Isolation

Conventional serving shares one application with broad backend privileges among clients; Single-Use Servers isolate each client in a separate application instance with user-tailored backend privileges and per-user execution logging. — Conventional web serving (top) multiplexes clients through a shared application instance with backend privileges sufficient for many users, creating a confused-deputy risk when the application is compromised. Single-Use Servers (bottom) instead route each client to a separately provisioned application instance with user-tailored backend privileges. This separates the execution and authority associated with different clients while providing per-user logging across HTTP activity, application execution, and backend queries.

Public-facing web applications commonly serve many clients through a shared application instance. A confused deputy problem arises when a program with greater authority is induced by a less-privileged party to misuse that authority. In a conventional shared-server architecture, the web application can become that deputy: it acts on behalf of many users and may hold backend privileges broad enough to support all of them. If an attacker compromises the application, they may be able to invoke backend operations using the application’s authority even when their own account would not be permitted to perform those operations.

Single-Use Servers change the unit of isolation from the application to the individual client. Each client is routed to a separately provisioned application instance rather than sharing one long-running server with other users. The instance can be assigned backend privileges tailored to that user, reducing the authority available if the instance is compromised and preventing one client’s server from simply inheriting privileges needed by other users.

These server instances are also disposable. When a client no longer needs an instance, it can be destroyed rather than reused by later clients. This limits the persistence of attacker-modified state and keeps a compromise isolated from the application instances serving other users.

Per-user isolation also provides a clearer basis for security analysis. HTTP activity, application execution, and backend queries can be associated with the same client-specific instance, making it easier to reconstruct what occurred during a session and investigate suspicious or compromised execution.

Project resources: Paper (DIMVA 2023) · Source code & installation tutorial · Project page at WPI

Related visualization work: PEGASUS (SANER/VST 2022) builds on SuS’s per-user logging infrastructure, combining web requests, database queries, and PHP execution traces in an interactive visualization to help analysts locate the code responsible for security vulnerabilities.