Hunting Reflected And Stored Xss

Hunting reflected and stored XSS: when data becomes markup in the wrong context

A cross-site scripting bug is an encoding failure with a location. The server takes untrusted data, reflected straight from the request or read back from storage, and writes it into an HTML response. If the value is encoded correctly for the exact place it lands, it stays inert data; if it is not, it becomes markup or script and runs in the victim's browser with the victim's session. The subtlety is that "correctly encoded" depends entirely on the output context: the escaping that neutralizes a value in an HTML body does nothing for a value inside an unquoted attribute, an inline script, a URL, or a stylesheet. So the hunt is not "is this escaped" but "is this escaped for the context it is actually in." You find these by locating every place server-rendered output includes untrusted data and matching the encoding to the context, then following whether delivery is reflected from the request or stored and served later.

When to use

• A server-side template or string-built response embeds request parameters or stored data into HTML.
• The framework autoescapes but code uses a raw, safe, or unescaped marker in places.
• User-controlled data is serialized into JSON or an attribute that a page then interprets.

Scope check

Test XSS only against applications you own or are authorized to assess, with test accounts, and use a harmless proof such as a benign marker rather than a real payload against other users, because stored XSS executes in every viewer's session. Clean up any stored test value you inject. If you can't name the authorization, stop.

The loop

1. Establish the exact output context and its encoding first. For each place untrusted data reaches the response, determine the precise context, HTML body, quoted attribute, unquoted attribute, inline script, URL, or CSS, and whether the encoding applied matches that context. This is the false-positive killer: HTML-entity encoding is correct in a body but useless inside a script block or an unquoted attribute, so an escaped value can still be XSS in the wrong place, and a value that never leaves a body with correct entity encoding is inert. Name the context and its encoding before judging.

2. Trace the data to the sink. Follow request parameters and stored fields into the template or the string that builds the response. Confirm the attacker controls the value and note whether it is reflected directly from the current request or was stored earlier and is served to other users.

3. Check autoescaping and its bypasses. Determine whether the template engine autoescapes by default, then find every raw, safe, unescaped, or trusted-HTML marker that turns it off. Those markers, and string concatenation outside the template engine, are where autoescaped applications still bleed.

4. Check the dangerous contexts specifically. Inline event handlers and script blocks, unquoted attributes, href and src URLs that may accept a script scheme, style blocks, and data attributes read by client code each need context-specific handling; entity encoding alone does not make them safe. Flag data landing in these without the right encoding.

5. Check the defenses that actually reduce impact. Determine whether a content security policy would block inline execution or restrict script sources, and whether output is built through a context-aware auto-escaping engine rather than manual string assembly. A strong policy lowers severity but a context-mismatched injection is still a finding.

6. Confirm and record. Confirm by injecting a benign marker that would only render as active markup if the context is unescaped (observing it parse as an element or execute a harmless proof), for stored XSS by viewing as a second account. Kill the lead if the value is encoded correctly for its context, if the engine autoescapes and no raw marker applies, or if the value never reaches an executable context. Record the sink, the context, reflected or stored, and the marker's behavior. Set kill_reason when killing.

Where XSS leaks

• The context decides safety, not the presence of escaping. Entity encoding is right for a body and wrong for a script block, an unquoted attribute, a URL, or CSS; match the encoding to the place.
• Raw and safe markers disable the default. An autoescaping engine protects until a template uses a raw, safe, or unescaped filter, or code concatenates HTML outside the engine.
• Stored XSS reaches every viewer. A value written once and served to others runs in each of their sessions, so an admin view of user-supplied data is a high-value target.
• URL and script-scheme contexts are easy to miss. A value placed into an href or src can carry a script scheme; entity encoding does not stop it, only scheme validation does.
• JSON embedded in HTML has two contexts. Data serialized into a script block must be safe both as JSON and against a closing script tag; encoding for one context leaves the other open.

Worked example (a confirm and a kill)

Confirm. A search results page reflects the query into the HTML body and also into an inline script variable. The body is entity-encoded, but the inline-script assignment concatenates the raw query, so a value that closes the script string and adds a statement executes in the visitor's session. A benign marker runs. Confirmed reflected XSS in an inline-script context, high, remediation = stop building inline script from untrusted data, serialize the value with a context-correct encoder or pass it through a data attribute read safely, and add a content security policy that forbids inline execution.

Kill. A comment feature stores user text and renders it through an auto-escaping template that entity-encodes into the HTML body with no raw marker, links are built by validating the scheme against an allowlist, and a content security policy forbids inline script and restricts sources. A stored value containing markup renders as visible text and does not execute in a second account's view. Killed, kill_reason = "value is entity-encoded for its body context by an auto-escaping engine with no raw marker, URL schemes are allowlisted, and the policy blocks inline execution, so injected markup stays inert."

Rationalizations to reject

• "We escape everything." -> Escaping for one context does not protect another; a body-escaped value in a script block or unquoted attribute is still XSS. Match the encoding to the context.
• "The framework autoescapes." -> Until a raw, safe, or unescaped marker turns it off or code builds HTML by hand; find those places rather than trusting the default globally.
• "It is only reflected, not stored." -> Reflected XSS is delivered by a crafted link and runs in the clicker's session; it is a full finding, not a lesser one.
• "A CSP protects us." -> A policy reduces impact and may block inline script, but a context-mismatched injection into an allowed source or a script-less sink can still fire; confirm, do not assume.
• "It is inside a JSON blob." -> JSON embedded in a page must also be safe against a closing script tag and the HTML context around it; JSON-encoding alone leaves that open.

Executing this in practice

You need every place server-rendered output includes untrusted data, the exact context each value lands in, and the encoding applied there, plus every raw or unescaped marker and every manual HTML concatenation. For each, decide whether the encoding matches the context and whether delivery is reflected or stored. Reading the template and the surrounding markup tells you the context; injecting a benign marker that only becomes active in an unescaped context, viewed as a second account for stored cases, tells you whether it executes.

Related

• testing-client-side-dom-vulnerabilities - the client-side variant where the sink is a DOM API rather than a server template; the same data may reach both, so check both.
• reviewing-content-security-policy - a policy is the compensating control that limits XSS impact; that skill covers whether the policy actually blocks inline and untrusted sources.
• hunting-content-type-and-parser-confusion - an upload the browser MIME-sniffs as HTML is a stored-XSS path through file handling rather than a template; adjacent sink.
• adjudicating-taint-paths - use it to connect a request field or a stored record to the exact output context through the rendering code.
• FINDING-SCHEMA.md - source = the untrusted data rendered into the page, sink = the HTML output context, evidence = a benign marker parsing as active markup or executing a harmless proof in the victim context.