EXERCISE 1 — Watching cookies attach in DevTools
=================================================

DOING IT:
  1. Log into a site, open DevTools (F12) -> Network tab.
  2. Trigger a request (click something, reload).
  3. Click the request -> Headers -> Request Headers -> find the
     "Cookie:" header, e.g.:
        Cookie: session_id=ab12cd34...; csrftoken=...
  4. (The Application/Storage tab also lists the stored cookies and their
     Domain, Path, SameSite, HttpOnly, Secure attributes.)

THE RULE THAT DECIDED THOSE COOKIES WERE ATTACHED:
  - The browser attached them based on the REQUEST'S DESTINATION (the
    domain/host the request is going TO), NOT based on which page you are
    currently on or which page initiated the request.
  - It looked up the cookies stored for the destination domain (matching
    domain + path + Secure, etc.) and included them automatically.

WHY THAT RULE ENABLES CSRF:
  - Because attachment depends only on the destination, a request to
    yourbank.com gets yourbank.com's cookies REGARDLESS of who triggered it.
  - So when a malicious page on evil.com causes a request to yourbank.com,
    the browser still attaches the victim's bank session cookie -- the
    attacker's page didn't need the cookie, the browser supplied it based on
    the destination.
  - That "destination-based, origin-blind" attachment is exactly the ambient
    authority that makes forged cross-site requests look authenticated.

NOTE: if you inspect the cookie's SameSite attribute (Chapter 7), a value of
Lax or Strict would CHANGE this behaviour for cross-site requests -- but the
DEFAULT/legacy behaviour you're observing here is the gap CSRF exploits.