EXERCISE 2 — Why re-authentication defeats CSRF on "change email"
=================================================================

THE DEFENCE:
  Before processing a sensitive action (change email), the server requires
  the user to RE-ENTER their CURRENT PASSWORD (or pass an MFA/OTP challenge)
  in that same request, and verifies it server-side.

WHY IT DEFEATS CSRF EVEN IF EVERYTHING ELSE IS BYPASSED:
  - CSRF works by getting the victim's BROWSER to send a request using the
    victim's ambient authority (the cookie). The attacker never learns any
    of the victim's actual secrets -- they ride the session blindly.
  - Re-authentication requires a value the attacker DOES NOT KNOW and CANNOT
    obtain via CSRF: the current password (or a live one-time code). A forged
    request can carry the cookie, a stolen-looking token, the right Origin --
    but it CANNOT contain the correct password, because:
       * the attacker doesn't know it, and
       * CSRF is write-only -- they can't read it off the page either
         (Same-Origin Policy), and they can't phish it through this channel.
  - So the server's password check fails on the forged request, and the email
    change is refused. The defence holds INDEPENDENTLY of tokens, SameSite,
    or Origin checks -- it relies on a user secret, a different assumption
    entirely. That's why it's the strongest single layer for high-value
    actions (true defence in depth: it fails for a different reason than the
    others).

CONNECTION TO THE CHAPTER 3 ACCOUNT-TAKEOVER CHAIN:
  - Recall the chain: forge "change email" -> attacker controls the recovery
    email -> use "forgot password" -> reset link goes to attacker -> full
    account takeover.
  - The whole chain HINGES on the first forged step (change email) succeeding
    blindly. Requiring the current password on that endpoint breaks step one:
    the forged change-email request can't supply the password, so it's
    rejected, the recovery email is never repointed, and the takeover chain
    never starts.
  - This is exactly why account-security endpoints (change email/password,
    add MFA/recovery method, delete account, payments) should ALWAYS demand
    re-authentication -- they're the highest-value CSRF targets and re-auth
    neutralises them by construction.

CAVEAT:
  Re-auth is friction, so reserve it for genuinely sensitive operations;
  keep tokens + SameSite as the broad baseline for everything else.