EXERCISE 2 — How a stored XSS becomes a self-propagating worm
==============================================================

THE WORM MECHANISM (Samy as the model):
  1. The attacker plants a payload in a STORED location that other users will
     view -- e.g. their own MySpace profile (stored XSS).
  2. When a VICTIM views the infected profile, the payload executes in the
     victim's authenticated session (it runs same-origin, in their context).
  3. Using SESSION RIDING, the payload makes authenticated requests AS THE
     VICTIM to write the SAME payload onto the victim's OWN profile (and, in
     Samy's case, to add the attacker as a friend).
  4. Now the victim's profile is infected too. Anyone who views THE VICTIM
     runs the payload, copies it to THEIR profile, and so on.
  5. Each infected profile infects every viewer -> exponential spread. Samy
     reached 1,000,000+ profiles in ~20 hours, forcing MySpace offline.

THE TWO REQUIRED INGREDIENTS:
  A. STORED XSS -- the payload must PERSIST somewhere served to many users
     (a profile, post, comment). This gives automatic execution on every view
     with no per-victim link, and a place to write copies into.
  B. SESSION RIDING -- the payload must be able to ACT AS THE VIEWING USER
     (make authenticated requests in their session) to write a fresh copy of
     itself into that user's own stored content. This is what turns "runs once
     per view" into "replicates to a new host per view."
  Stored XSS provides the persistence + reach; session riding provides the
  self-copy. Together they create a worm.

WHY REFLECTED XSS GENERALLY CAN'T SELF-PROPAGATE THE SAME WAY:
  - Reflected XSS isn't stored: the payload only exists in a specific crafted
    REQUEST/URL and affects only the one person who follows that link. There's
    no persistent location that automatically serves the payload to other
    users.
  - For propagation you'd need each newly-infected user to somehow distribute
    a malicious LINK to others and get them to click it -- which requires user
    action and social distribution, not automatic replication. There's no
    "view a normal page -> get infected -> infect your own page" loop, because
    nothing is stored and served onward.
  - Hence worms are essentially a STORED-XSS phenomenon: the stored, served-to-
    all property is what enables hands-free chain infection. (DOM-based stored
    variants can also worm if the malicious data is persisted and re-served.)

DEFENSIVE TAKEAWAY:
  A single stored-XSS hole on a high-traffic social feature is not one
  compromise -- it's a potential epidemic. This is a major reason stored XSS
  is rated the most severe type (Chapter 2).