Middleware, databases and browsers

Middleware is the software that connects components, whether on one host or across several: message brokers such as AMQP, and remote procedure call systems such as Java RMI, CORBA and XML-RPC. Distribution is what makes its access control difficult. A middleware component has to define its permissions at the right granularity, keep track of who currently holds which right, and enforce that continuously, across machines that do not share one administrator. Policy languages exist to write these rules down, but the lecture is blunt about them: they are hard to use correctly, and a rule nobody can read correctly is a rule nobody can audit correctly either.

Middleware is also exposed. Because it usually has to talk across a network, it can be probed from outside. Restricting it to internal traffic closes off random, remote exploitation, but it does nothing against malware that starts inside one of the systems the middleware connects and works outward from there.

Database access control layers on top of this. A database management system that supports multiple users and processes runs its own access control, separate from the operating system’s. Connecting still requires a username and password, authentication first, the same as everywhere else in this module, and the DBMS then runs its own internal privilege system, typically by mapping operating-system accounts onto roles defined inside the database rather than managing every user’s rights one at a time.

The SQL standard defines access control down to a fine grain: in principle, almost any object inside the database can be individually controlled. That precision has a cost. A system with that many controllable objects is easy to specify into something too complicated to manage correctly. The DBMS also runs its own integrity checks on the data it holds, and those checks are accurate but computationally heavy to run.

None of this replaces the operating system’s own protections. A database’s rows and tables are, physically, files on disk or pages in RAM, and an attacker who bypasses the DBMS and reads those files directly bypasses every role and permission the database defined.

Browsers are a third middleware layer, and the one every user interacts with directly. The core access control rule is the same-origin policy: active content such as JavaScript may only communicate back to the origin it was loaded from. Code on a page runs inside a sandbox, a restricted environment meant to stop it altering the host system outside the browser. Chrome goes further and runs each tab in its own operating-system process, so a script that hangs one tab does not take the whole browser down with it.

The same-origin policy checks where code was loaded from, not who wrote it. That gap is what makes the confused deputy problem possible in a browser. A privileged program is asked to do something, and does it with its own authority rather than the authority of whoever actually asked. That is the confused deputy problem, and in a browser the deputy is the browser itself.

The lecture walks through it as cross-site scripting, in three steps. A user visits a trusted site that has an XSS vulnerability, and the attacker has already injected a malicious script into it. When the user’s browser loads the page, the injected script runs as if it were the site’s own code, with the site’s permissions rather than the attacker’s. The script then acts with the site’s authority, sending authenticated requests or reading sensitive data, because the browser believes those actions genuinely come from the site it trusts.