Confused-deputy

A confused-deputy problem is a classic computer security vulnerability where a program (the "deputy") is tricking itself into using its own elevated authority or privileges to perform an action on behalf of an untrusted user (the "client") that the client should not be allowed to perform.

The deputy is "confused" because it cannot distinguish between its own permissions and the permissions of the party asking it to perform a task.

The Classic Analogy: The Compiler & The Bill

The term was coined in 1988 by Norm Hardy, who illustrated it with a scenario on a multi-user system:

1. The Deputy: A system compiler runs with elevated privileges so it can write to a central system billing file (/sys/bill) to log usage every time a user compiles code.
2. The Client: An unprivileged user submits a file to compile and instructs the compiler to write output or debug logs to a specific path: /sys/bill.
3. The Confusion: The compiler opens /sys/bill on behalf of the user. Because the compiler itself has permission to edit /sys/bill, the OS allows the write operation, overwriting critical system billing data with user output.

The compiler acted as a deputy for the user, but used its own authority rather than validating whether the user had the authority to write to /sys/bill.

Core Characteristics

A confused-deputy situation occurs when three elements align:

• Privilege Separation: System A has higher privileges than System B.
• Ambient Authority: The system grants permissions based on who is running the code (e.g., process identity or service account role) rather than attaching capabilities directly to the request/data payload.
• Insufficient Input Validation: The privileged system executes requests from less privileged entities without verifying if the caller holds the required permissions for the target resource.

Real-World Modern Examples

Cloud Infrastructure (e.g., AWS IAM)

In cloud environments, a third-party SaaS service (Deputy) might ask for access to perform tasks inside your AWS account (Client).

• If the SaaS service asks you to grant its central AWS IAM role permission to access your S3 bucket, a malicious third party could trick that same SaaS service into accessing your S3 bucket on their behalf.
• Fix: AWS solved this by requiring an External ID—a unique secret passkey generated between you and the vendor—in the IAM role trust policy to ensure the deputy knows precisely on whose behalf it is acting.

Cross-Site Request Forgery (CSRF)

Web browsers act as deputies for users:

• When you visit evil-website.com, it sends a background request to [your-bank.com/transfer](https://your-bank.com/transfer).
• The browser automatically attaches your authentication cookies for your-bank.com because it holds that authority ambiently.
• The bank's server executes the request because the browser (the deputy) presented valid session credentials on behalf of a malicious site.
• Fix: CSRF tokens and SameSite cookies explicitly bind authority to the specific request origin rather than ambient browser sessions.

Web Browsers & Local File Access

A web browser running on your local machine has privilege to read local files. If a malicious webpage tricks the browser engine into reading file:///etc/passwd and exfiltrating it over the network, the browser acted as a confused deputy.

Prevention & Mitigation

• Capability-Based Security: Replaces ambient authority with explicitly passed tokens/capabilities. The deputy can only access a resource if the client provides a valid, unforgeable capability token specifically for that resource.
• Privilege Attestation / Identity Passing: Instead of acting on its own identity, the deputy impersonates or forwards the client’s identity to the target service (e.g., OAuth tokens, user delegation tokens).
• Cross-Account Secrets (External ID): Cloud systems require unique caller identifiers when configuring service trusts to bind cross-account requests to specific clients.