EXERCISE 2 — How a forged "change email" becomes account takeover
==================================================================

THE ESCALATION CHAIN:
  1. The attacker forges a single request: change the victim's account email
     to attacker@evil.com (an auto-submitting POST while the victim is logged
     in). One CSRF, one state change.
  2. The account's registered email is now an address the ATTACKER controls.
  3. The attacker goes to the app's normal "Forgot password?" flow and
     requests a reset for the victim's account.
  4. The reset link / code is emailed to the account's registered email --
     which is now attacker@evil.com.
  5. The attacker clicks the link, sets a new password, and now owns the
     account outright. The legitimate user is locked out.

  So a LIMITED capability (cause one state change, can't read anything) chains
  into FULL account takeover by abusing a legitimate downstream feature
  (password reset by email). The CSRF didn't need to read a response -- it
  just repointed the recovery channel.

WHY THE ATTACKER CAN CHANGE THE EMAIL BUT NOT READ THE CONFIRMATION:
  - CHANGE (write): a credentialed cross-site POST is SENT and the server
    PROCESSES it (Chapter 2). The browser allows the send; the server sees a
    valid cookie and performs the change. The action happens.
  - READ (response): the Same-Origin Policy blocks the attacker's page from
    READING target.com's response. So the attacker never sees the "email
    changed" confirmation page or any returned data.

WHY NOT READING THE RESPONSE DOESN'T SAVE THE VICTIM:
  - The attacker doesn't NEED the response. The goal was the SIDE EFFECT (the
    email is now theirs), not the confirmation text. Blind success is still
    success.
  - The confirmation/verification then arrives THROUGH A CHANNEL THE ATTACKER
    NOW CONTROLS (the new email), so even an "are you sure?" email lands in
    the attacker's inbox.
  - Hence "write-only" is not reassuring for high-value endpoints: a blind
    write to the right endpoint is catastrophic.

DEFENSIVE TAKEAWAY:
  Account-security endpoints (change email/password, add recovery method)
  need the STRONGEST CSRF protection AND step-up RE-AUTHENTICATION
  (re-enter current password), so a forged blind request can't succeed even
  if a token were somehow obtained. (Chapter 8.)