EXERCISE 2 — The five steps of the forged-transfer attack
==========================================================

THE SEQUENCE:
  Step 1. The victim logs into yourbank.com.
          -> The browser stores a valid SESSION COOKIE for yourbank.com.

  Step 2. While still logged in, the victim visits evil.com (via a link,
          ad, or email).
          -> evil.com loads in the browser; the bank session is still active.

  Step 3. evil.com's hidden form AUTO-SUBMITS a POST to
          https://yourbank.com/transfer (its <script> calls form.submit()).
          -> A cross-site request to the bank is now in flight.

  Step 4. *** THE COOKIE GETS ATTACHED HERE ***
          -> The BROWSER (not evil.com, not the attacker) automatically adds
             the victim's yourbank.com session cookie to the outgoing
             request, because the request targets yourbank.com. This is
             ambient authority. evil.com never sees or touches the cookie.

  Step 5. yourbank.com receives a request bearing a valid session cookie,
          sees a legitimate-looking authenticated user, and EXECUTES THE
          TRANSFER to the attacker's account.

WHICH STEP ATTACHES THE COOKIE, AND BY WHOM:
  - Step 4, and it's done by the VICTIM'S BROWSER following its normal
    "send this domain's cookies to this domain" rule — not by the attacker's
    code. The attacker only supplied the form/parameters in Step 3.

WHICH STEP A SECRET, UNPREDICTABLE VALUE WOULD PREVENT:
  - Step 5 (the server executing the action) — and effectively Step 3's
    usefulness. If the bank required a secret value the attacker can't
    predict (e.g. a per-session CSRF token embedded in the REAL form), then
    evil.com's forged form can't include the correct value. The submitted
    request would arrive WITHOUT a valid token, so the server rejects it in
    Step 5 instead of executing the transfer.
  - This attacks PRECONDITION 2 (forgeable parameters): the request now
    depends on a value the attacker cannot guess, so they can't forge a
    valid request even though the cookie still gets attached in Step 4.

KEY INSIGHT:
  The cookie attachment (Step 4) is unavoidable with cookie auth — so
  defences instead make the REQUEST ITSELF unforgeable (a secret token) or
  stop the cookie being sent cross-site (SameSite, Chapter 7).