EXERCISE 1 — Classify the XSS type =================================== (a) A script in a ?q= URL parameter echoed into search results. TYPE: Reflected XSS. WHY: the payload arrives in the immediate REQUEST (the ?q= parameter) and the server reflects it straight back into the response page without encoding. It isn't stored -- only the person who makes that request is affected, so the attacker must deliver the crafted URL to a victim. REACHES THE SERVER? YES -- the query string is sent to the server, which echoes it. (So server-side output encoding fixes it.) (b) A script saved as a product review and shown to all shoppers. TYPE: Stored XSS. WHY: the payload is PERSISTED on the server (the review is saved to the database) and later served to EVERY user who views the product page, with no special link needed. One injection hits all viewers automatically -- the most dangerous pattern. REACHES THE SERVER? YES -- it's stored on and served by the server. (Server-side encoding on output fixes it.) (c) The page's JS reading location.hash into innerHTML. TYPE: DOM-based XSS. WHY: the unsafe insertion happens entirely in CLIENT-SIDE JavaScript -- the page reads attacker-controllable input (location.hash) and writes it into a dangerous sink (innerHTML). No server code does the injecting. REACHES THE SERVER? OFTEN NO -- the URL FRAGMENT (everything after #) is NOT sent to the server by the browser. So the malicious data may never touch the backend, and server-side encoding does nothing. Fix the client JS (use textContent / a safe sink). SUMMARY: (a) Reflected -- request-echoed, reaches server, server-fixable (b) Stored -- persisted & served to all, reaches server, server-fixable (c) DOM-based -- client JS sink, fragment may not reach server, client-fix KEY DISTINGUISHER between (a) and (c): both are per-request and URL-driven, but in (a) the SERVER inserts the payload unescaped, while in (c) the PAGE'S OWN JS does. "Who performs the unsafe insertion?" decides reflected vs DOM.