EXERCISE 3 — Why stored XSS is usually rated more severe than reflected
=======================================================================

WHY STORED IS USUALLY MORE SEVERE:

  1. PERSISTENCE.
     - Stored: the payload is saved server-side and keeps executing for every
       view until someone finds and removes it. It can lurk for a long time.
     - Reflected: the payload exists only in a single crafted request; nothing
       persists. Each victim needs a fresh delivery.

  2. VICTIM REACH (automatic, mass).
     - Stored: EVERY user who simply visits the affected page (e.g. a popular
       comments/reviews/profile page) runs the payload -- no per-victim effort.
       One injection -> potentially thousands of victims, including admins.
     - Reflected: only the people the attacker individually lures into clicking
       the malicious link are affected -- reach is bounded by the phishing
       campaign's success.

  3. DELIVERY REQUIREMENT (no user action beyond normal use).
     - Stored: the victim does nothing unusual -- they visit a legitimate page
       they already trust. No suspicious link to notice or avoid.
     - Reflected: requires the victim to follow an attacker-supplied URL, which
       can look suspicious, be filtered by email/security tools, or simply be
       ignored. Higher friction, lower success rate.

  4. SELF-PROPAGATION.
     - Stored XSS on a social feature can become an XSS WORM: the payload posts
       itself to other users' profiles, spreading exponentially (e.g. the Samy
       worm). Reflected XSS can't self-propagate this way.

  NET: stored combines persistence + automatic mass reach + low delivery
  friction + worm potential, so it's typically the highest-impact XSS.

A CASE WHERE REFLECTED IS MORE DAMAGING THAN A PARTICULAR STORED XSS:
  - Reflected XSS on a BANK'S LOGIN PAGE vs stored XSS in an obscure internal
    admin note only one low-privilege user ever reads.
  - The reflected bug, though it needs a clicked link, targets a HIGH-VALUE
    context: a phishing email with the malicious link lands users on the REAL
    bank domain (so the URL/cert look legitimate), and the injected script can
    capture credentials or hijack the authenticated session of anyone who
    logs in. The payload runs in a security-critical page for many targeted
    users.
  - The stored bug, by contrast, sits on a rarely-viewed page with tiny reach
    and low privilege, so its persistence buys little.
  - LESSON: severity = (impact of the context) x (reach) x (ease), not just
    "stored vs reflected." A reflected XSS in a critical, high-traffic flow
    can outweigh a stored XSS in a backwater. Classify by type, but RATE by
    context.