xss-browser-confirm - SKILL.md Agent Skill

name: xss-browser-confirm description: Turn a suspected Cross-Site Scripting reflection or DOM sink into proof of JavaScript execution by firing a uniquely-tagged dialog in a real headless browser via the browser_probe tool — not by string-matching the response. Covers reflected, stored, and DOM-based XSS, context-aware payload crafting (HTML body, attribute, JS string, URL/href, DOM sink), light WAF/encoding evasion when a payload reflects but doesn't execute, and persisting a finding sized by real impact. Use when a parameter's value appears in the response, when a DOM sink (innerHTML, document.write, eval, location) consumes input, when CWE-79 was flagged, or when a scanner saw reflection but couldn't confirm execution. license: MIT tags: - xss - dom - browser-confirm allowed-tools: - query_records - inspect_record - replay_request - browser_probe - report_finding - update_finding - remember - update_plan

XSS → Browser-Confirmed Execution

You suspect XSS somewhere. Reflection is a hint, not proof. Your job is to make JavaScript actually run in a real browser and capture the proof — then persist a finding with the exact URL that executed. browser_probe loads a URL in headless Chrome and reports any alert/confirm/prompt dialog that fires, even when nothing reflects visibly in the HTML. That dialog is your oracle.

When this skill applies

A URL/body/header param value appears in the response body or a header.
A scanner/audit flagged CWE-79, "reflected XSS", "DOM XSS", or "reflection observed, execution unconfirmed".
The page's JS feeds input into a sink: innerHTML, outerHTML, document.write, eval, setTimeout(string), location/href, $(...).html(), dangerouslySetInnerHTML.

If you only have "fuzz everything", anchor on a record first (query_records for reflected params / search endpoints, then inspect_record). Don't probe blind.

The canary discipline

Use one unique canary per probe so a dialog can't be a coincidence or a leftover from another page. Make it specific and greppable, e.g. alert('xss-9f3a2c'). After browser_probe, the proof is dialog_fired == true and the dialog message equals your canary. A dialog with a different message is the app's own JS — not your finding.

remember the canary + target as xss-target so it survives context churn.

Workflow

1. Anchor and find the reflection / sink

inspect_record the candidate. Find where the input lands:

In the response body → reflected; note the surrounding bytes.
Consumed by client JS with no server reflection → DOM-based; read the JS to find the sink and the source (location.hash, location.search, document.referrer, postMessage).
Persisted then rendered on another page (profile, comment, admin panel) → stored; note the injection request and the rendering URL.

2. Classify the injection context

The payload must break out of its context. Identify which one:

HTML element body (<div>HERE</div>): <script>alert('c')</script> or, if <script> is stripped, <img src=x onerror=alert('c')>.
HTML attribute (value="HERE"): close the attribute/tag first — "><img src=x onerror=alert('c')> or, inside an event-capable tag, " onmouseover=alert('c') autofocus tabindex=1 x=".
JS string literal (var q='HERE'): close the string — ';alert('c')// or </script><script>alert('c')</script>.
URL / href sink (<a href="HERE">, location='HERE'): javascript:alert('c').
DOM sink (el.innerHTML = location.hash.slice(1)): put the payload in the fragment — #<img src=x onerror=alert('c')> — see step 4.

3. Confirm reflected XSS

Build the full URL with the payload in the query string and call browser_probe:

url: the endpoint with ?param=<url-encoded payload>.
wait_ms: bump to 1500 if the app defers work (SPA hydration, setTimeout-wrapped sinks); the default 700 misses late dialogs.
wait_selector: optional CSS selector to wait for before sampling.

Read the result: dialog_fired:true + message == canary → confirmed. If the value reflects in the HTML but no dialog fires, it's reflected-only (likely encoded or CSP-blocked) — go to step 6, don't report yet.

4. Confirm DOM-based XSS

DOM XSS often lives in the fragment, which the server never sees (so server-side reflection and WAFs are blind to it). Put the payload after #:

url: https://target/page#<img src=x onerror=alert('c')> (or #javascript:alert('c') for a location sink).
browser_probe executes the page's real JS, so a vulnerable innerHTML = location.hash fires the dialog. No dialog → the sink sanitizes or the source isn't what you think; re-read the JS.

5. Confirm stored XSS

Two steps:

replay_request the write that persists your payload (post a comment, update a profile field) with the canary payload in the stored field.
browser_probe the rendering page (where the stored value is shown, often an admin/other-user view). Dialog fires there → stored XSS, which is higher impact than reflected (no user interaction / victim is whoever views the page).

Note the rendering context in the finding — "fires in the admin moderation queue" is materially worse than "fires on the author's own page".

6. Reflected-but-not-executing: light evasion

If the payload reflects but no dialog fires, the value is encoded, filtered, or CSP-blocked. Iterate a few targeted variants — don't brute force:

Case / tag mutation: <sCRipt>, <svg/onload=alert('c')>, <img src=x onerror=alert('c')> when script is filtered.
Encoding: HTML entities, URL double-encoding, or splitting filtered keywords; match the encoding to where reflection lands.
Attribute breakout variants if > or " is stripped but the other isn't.
CSP check: if final_url/headers show a strict Content-Security-Policy with no unsafe-inline, inline handlers won't run. Note the CSP — it can downgrade or block the finding; an injection that can't execute under the deployed CSP is at most informational. Look for a CSP bypass (allowed CDN, nonce reuse, JSONP endpoint) before claiming execution.

Re-browser_probe after each variant. Stop after a handful; if nothing fires, report it as reflection-only (low/informational) with the encoding you observed, not as confirmed XSS.

7. Persist the finding

report_finding once per distinct sink:

severity: stored → high/critical; reflected with execution → high; DOM with execution → high; reflection-only / CSP-blocked → low or informational.
title: type + endpoint + param/sink, e.g. "Reflected XSS in /search?q executes arbitrary JS" or "DOM XSS via location.hash → innerHTML on /dashboard".
cwe_id: CWE-79.
description: 2–3 sentences — context, the payload, that a real browser fired alert(<canary>), and the rendering context for stored XSS.
Include the exact URL (or the write request + rendering URL for stored) that fired the dialog — this is the reproducible proof.

If the audit harness already filed a theoretical XSS for the same sink, update_finding with status: triaged and the browser-confirmed evidence instead of double-reporting.

Pitfalls — read before claiming

Reflection ≠ execution. Never report XSS off a string match alone. The dialog from browser_probe is the bar.
Match the canary. A fired dialog whose message isn't your canary is the app's own code; keep the canary unique per probe.
Deferred alerts need a larger wait_ms — a sink wrapped in setTimeout/requestAnimationFrame won't fire within the default window.
Fragments aren't sent to the server. For DOM/hash XSS, the WAF and server logs won't show it — that's expected; the browser still executes it.
CSP can make a "working" payload inert in production. Always check whether inline execution is actually allowed before sizing the finding.
One report_finding per sink, not per payload variant tried.

Output expectations

One finding per confirmed sink, each with a browser-fired-dialog proof URL.
A remember note with the canonical confirming URL + canary.
The plan item that triggered this skill marked done via update_plan.