Cross-Site Request Forgery — The Confused Deputy Attack
In 2008, security researchers discovered a CSRF vulnerability in the administration panels of widely deployed home routers — including models from Linksys and D-Link. The attack was devastatingly simple: a malicious web page contained a hidden form that submitted a DNS-change request to http://192.168.1.1/setup.cgi. Any home user who happened to visit that page while their router's admin session was active would unknowingly redirect all DNS lookups through attacker-controlled servers — enabling phishing, credential theft, and traffic interception at scale. No authentication bypass was needed. The browser did all the work.
This is the confused deputy problem in web security. The browser is a trusted intermediary: it holds your session cookies and acts on your behalf. An attacker's page can instruct that trusted deputy to make authenticated requests to any site where you are logged in — without your knowledge or consent.
The reason this works comes down to one of the web's foundational behaviours: browsers automatically attach cookies to every request for a matching domain, regardless of which page initiated the request. When you are logged in to securebank.io and you visit evil.com, any form or script on evil.com can trigger an HTTP request to securebank.io. The browser dutifully appends your securebank.io session cookie. The server sees a valid authenticated request and has no built-in way to know it was forged.
The Same-Origin Policy restricts scripts from reading responses across origins, but it does not prevent cross-origin requests from being sent. This distinction is crucial: SOP protects data exfiltration, not request forgery.
State-changing operations — changing an email address, transferring money, deleting an account — are the primary targets. If the server processes such a request without verifying it was intentionally initiated by the legitimate user, the attacker wins.
What You Will Do in This Lab
You will put yourself in the attacker's position. The lab presents SecureBank's legitimate "Change Email Address" form, complete with its form action URL, field names, and a CSRF token that the server should validate. Your task is to study that form and construct an auto-submitting HTML proof-of-concept that, when visited by a logged-in Alice, would silently change her email address to [email protected].
By building the PoC yourself you will understand precisely what information an attacker needs, why CSRF tokens and the SameSite cookie attribute are effective defences, and what a vulnerable endpoint looks like in practice.