Cross-Site Request Forgery

What Is Cross-Site Request Forgery?

Cross-Site Request Forgery (CSRF) abuses the browser's default of attaching the session cookie to every request that targets the cookie's domain, including cross-site form submissions that the user did not deliberately initiate. The hostile primitive is any page on a different origin that crafts a POST/PUT/DELETE to the victim application: a hidden form that auto-submits when the page loads, a fetch() call with credentials: 'include' , an image src that triggers a GET-with-side-effects. The server receives the request with the victim's session cookie attached, looks up the session, and authorises whatever the body says, because nothing in the request distinguishes 'user clicked the legitimate button' from 'attacker auto-posted from another origin'. This exercise puts you on both sides. As Bob, you host a coupon page with a hidden form that auto-submits a $9,800 transfer to Westmark Industrial's procurement portal. The victim, who is already logged into the portal in another tab, opens your coupon page (paid traffic, phishing email, anything click-driven) and the transfer executes silently. As Alice, on the receiving end of a fraud-monitor alert flagging a $9,800 transfer with Origin: sunbean-rewards.com , you open the transfer handler, see authentication via session cookie alone, and apply the fix: a per-session CSRF token check before any mutation. The exercise closes with quiz questions on what CSRF is, why the Same-Origin Policy makes the token defence work, and what SameSite=Strict on the session cookie adds on top.

What You'll Learn in Cross-Site Request Forgery

• Recognize CSRF as the consequence of browser-default cookie attachment plus session-cookie-only authentication on state-changing endpoints
• Apply per-session CSRF token validation on every POST/PUT/DELETE handler that mutates state
• Pair the token check with <code>SameSite=Strict</code> on the session cookie so the browser does not even attach the cookie to cross-site requests, defence-in-depth at the cookie-attachment layer
• Understand that the Same-Origin Policy makes CSRF tokens work: attackers can SEND cross-site requests but cannot READ responses to extract the token
• Audit every state-changing endpoint (role grants, account updates, password change without current password, settings save, transfer execution) for the same shape

Cross-Site Request Forgery — Training Steps

1. A routine transfer

   Westmark Industrial runs an internal procurement portal to authorise vendor payments. Alice has one small transfer to send this morning: $247.50 to Hartwell Logistics for a routine delivery. Behind the scenes the portal authenticates every request with her session cookie. Log in and see how a normal transfer works.

2. Sign in to the portal

   This is the portal Alice uses to authorise vendor payments. Her session stays active in this tab for the rest of the day.

3. Authorise the transfer

   Send $247.50 to Hartwell Logistics. The form posts to the transfer endpoint with the amount and recipient in the request body. Alice's session cookie rides along automatically: that is the only thing that proves the request is hers.

4. Posted to the ledger

   The transfer lands in recent activity. The cookie was valid, the body was well-formed, and the portal authorised it. Notice what it did not require: no secret in the body, nothing only the real form could supply. The session cookie alone was proof enough.

5. The request he cannot send

   Bob cannot reach into Westmark Industrial's accounts. But he knows the transfer endpoint authorises whatever a signed-in employee's browser sends, and he knows employees stay logged in all day. He cannot send the request himself: it only counts if it comes from an employee's authenticated browser. So he builds a page that sends it for him. This cheerful coupon page is all a visitor ever sees.

6. Under the coffee page

   The coffee page is a decoy. Open its source and see what really sits underneath the friendly heading.

7. Inside the trap

   Underneath the friendly heading sits the real payload. Step through it: a hidden form that posts to Westmark Industrial's real transfer endpoint the instant the page loads, carrying Bob's numbers, not the visitor's.

8. Send the lure to Alice

   The page is armed. Now Bob wraps it in a cheerful coupon email and sends it to Alice's work address, then waits for her to open it while her portal session is still live.

9. A free-coffee email

   Later that evening, off the clock, Alice gets a cheerful email: a free coffee, one click to claim. Nothing asks for a password. Her portal tab from this morning is still open in the background.

10. Look closer

    Nothing in the email asks for credentials or a download. It is just a link to a coupon page, the kind most people skim and click.