Cross-Site Request Forgery

What Is Cross-Site Request Forgery?

Browsers attach a site's session cookie to requests fired from any origin, and cross-site request forgery lives in that default. You'll build a coupon page whose hidden form submits itself and wires money out of a portal the victim is signed into in another tab. Then you take the fraud alert, spot the giveaway Origin header, and fix the handler with a per-session token plus SameSite=Strict . The token works because an attacker can send a cross-site request but never read the response.

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.