Middleware, databases and browsers

Middleware is hard to protect because it is distributed and exposed

Access control does not stop at the operating system. A request for accounting data might pass through a message broker, then a database engine, then a web page in a browser, and each layer makes its own access decision on its own model before the operating system sees the request. The further data travels from the machine it started on, the harder it gets to say who should be allowed to touch it.

Middleware is the software that connects components, on one host or 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 that they are hard to use correctly, and a rule nobody can read correctly is a rule nobody can audit.

Middleware is also exposed: because it talks across a network, it can be probed from outside. Keeping it to internal traffic closes off random, remote exploitation, but does nothing against malware that starts inside one of the connected systems and works outward from there.

A database enforces its own roles, but the files underneath still need the OS

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, as everywhere in this module), and the DBMS then runs its own privilege system, typically 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 can be individually controlled. That precision has a cost, since 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 its data, accurate but computationally heavy.

None of this replaces the operating system’s 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.

Exam detail

Two separate costs: SQL’s fine-grained model can be over-specified into something too complex to manage, and its integrity controls are accurate but expensive to check. Neither fixes the other: a simpler policy does not make integrity checking cheaper, and faster checking does not make a sprawling policy easier to audit.

The same-origin policy checks where code came from, so it cannot stop a confused deputy

Browsers are a third middleware layer, and the one every user touches. The core rule is the same-origin policy: active content such as JavaScript may only communicate back to the origin it was loaded from. Page code 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.

The policy checks where code was loaded from, not who wrote it. That gap makes the confused deputy problem possible. A privileged program is asked to do something, and does it with its own authority rather than the authority of whoever actually asked. In a browser the deputy is the browser itself. The lecture walks through it as cross-site scripting (XSS), in three steps:

1. A user visits a trusted site with an XSS vulnerability, and the attacker has already injected a malicious script into it.
2. The user’s browser loads the page, and the injected script runs as if it were the site’s own code, with the site’s permissions rather than the attacker’s.
3. The script 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.

the deputy — acts with authority that is not its own to give awayattacker-controlled step

A privileged program is asked to do something and does it with its own authority rather than the requester's. That is the confused deputy problem. In the browser, the deputy is the victim's own browser: once an attacker gets a script injected into a trusted site (an XSS flaw), the browser runs that script as if it came from the site, because the same-origin policy only checks where the code loaded from, not who actually wrote it. The script then acts with the site's session and cookies, not the attacker's own — the trusted site's deputy has been confused about who it is really acting for. (source: Week 3 notes §4.2)

Because the script loads from the trusted site’s own origin, the same-origin policy protects it exactly as if it were the site’s code, and the browser carries out its requests with the site’s session and cookies. The sandbox does not help either: it limits what the script can do to the computer, not what it can do with the site’s authority inside the browser, which is the channel XSS abuses. Chrome’s per-tab isolation limits how far a compromised tab affects the rest of the browser, but that is containment, not a fix for the trust gap. Week 3 leaves the actual XSS defences to the web security lecture.

Pitfall

Do not describe the confused deputy problem as the browser being hacked. Nothing needs to compromise the browser at all. The browser is doing exactly what it is designed to do, run the site’s code with the site’s authority, and the problem is that the code running is not really the site’s.

Recall

Why doesn't the same-origin policy stop the XSS version of the confused deputy problem?

Because it checks where the code was loaded from, not who wrote it. An attacker’s script injected into a trusted page loads from that page’s own origin, so the same-origin policy treats it exactly like the site’s own code.

Optional aside

Pages loaded with trackers from many ad networks already make the same-origin policy’s intent look thin, and an attacker can launder an origin by wrapping a target site in a proxy such as a translation service. This is scene-setting for the web security lecture, not a tested fact on its own.