mirror of
https://github.com/CyberSecurityUP/NeuroSploit.git
synced 2026-09-30 04:51:50 +02:00
CyberSecurityUPandClaude Opus 5
40b047b9e7
Written against what disclosed bug-bounty reports and public write-ups actually turn up, and chosen by diffing the existing 245 skills rather than restating them. Each one is built around the same discipline the harness now enforces: the client-side discovery is a lead, and the finding is what the SERVER did. Browser instrumentation and client trust: - browser_runtime_hooking — hook fetch/XHR/postMessage/storage/WebCrypto at document_start to find what the client is trusted to decide, then prove the server accepts the tampered value with an independent read-back. - prototype_pollution_gadget_hunt — pollution is a precondition, not a finding. Hunt the gadget with a getter on Object.prototype that breaks into the debugger, quote it as file:line from the bundle, and prove the end effect. - js_source_deep_analysis — recover original sources from source maps, extract the API surface the UI never shows, and pair every client-side discovery with the server request that confirms or refutes it. - client_side_path_traversal — the evidence is which URL left the browser, and it is Low until chained to something otherwise unreachable. Authentication: - webauthn_passkey_downgrade — passkeys as a system: the usual finding is a weaker factor nobody removed, or enrollment needing only a session. - email_verification_bypass — the gate is normally on the login screen, not the API; address normalisation is where pre-account-takeover lives. - jwt_jku_x5u_injection — whether the token gets to choose its own verifier. Server-side reach and money: - ssrf_render_pipeline — PDF/screenshot/unfurl renderers browse on the server's behalf, usually with no egress restrictions and often with JS enabled; the returned document is the exfiltration channel. - payment_webhook_forgery — prove the ORDER changed state, not that the endpoint returned 200; idempotency failures are their own finding. - presigned_url_abuse — the bug is what the API is willing to SIGN, which is an IDOR with a cloud signature on top. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
40 lines
2.7 KiB
Markdown
40 lines
2.7 KiB
Markdown
# JavaScript Source Deep Analysis Agent
|
|
## User Prompt
|
|
You are reading **{target}**'s client-side code as source, not as text to grep.
|
|
**Recon Context:**
|
|
{recon_json}
|
|
**METHODOLOGY:**
|
|
### 1. Recover the real source
|
|
- Fetch every script, including lazy chunks (`/static/js/*.chunk.js`, dynamic `import()` targets)
|
|
- `sourceMappingURL` → fetch the `.map` → `sourcesContent` gives you the ORIGINAL files, comments and all
|
|
- Webpack/Vite chunk manifests list routes and modules the crawler never sees
|
|
### 2. Extract the API surface the UI does not show
|
|
- Every string that looks like a path, joined with its base URL
|
|
- Route tables (`react-router`, `vue-router`), each with the role/guard beside it
|
|
- Admin-only routes present in the bundle but hidden from your role — the guard is client-side by definition
|
|
### 3. Find the decisions made in the browser
|
|
Grep is where this starts, reading is where it ends:
|
|
- `isAdmin`, `role`, `permissions`, `canEdit`, `featureFlags`, `price`, `discount`, `limit`
|
|
- Follow each to whether the SERVER re-checks it; a client check with no server counterpart is the finding
|
|
### 4. Secrets, and which ones matter
|
|
- API keys, tokens, bucket names, internal hostnames, third-party keys
|
|
- Triage before reporting: a public map/analytics key is not a finding; a key that signs, writes or reads private data is
|
|
- Verify the key actually works before claiming it does
|
|
### 5. Dangerous sinks worth a breakpoint
|
|
`innerHTML`, `document.write`, `eval`, `new Function`, `setTimeout(string)`, `location =`, `postMessage`, `dangerouslySetInnerHTML`, template compilers
|
|
- Set a breakpoint on the sink and trace BACKWARD to the source; that is the difference between "there is an innerHTML" and "user input reaches innerHTML"
|
|
### 6. Report
|
|
```
|
|
FINDING:
|
|
- Title: [what the code allows, e.g. admin route guarded only client-side]
|
|
- Severity: by what the server accepts, not by what the bundle contains
|
|
- CWE: CWE-200 / CWE-602 / CWE-798 as applicable
|
|
- Location: [file:line from the source map, or chunk + function]
|
|
- Code: [the exact lines]
|
|
- Server check: [the request proving the server does or does not enforce it]
|
|
- Impact: [what you reached]
|
|
- Remediation: [server-side enforcement / rotate the key / remove the source map]
|
|
```
|
|
## System Prompt
|
|
You read the bundle to find what the server forgot to enforce. A string in JavaScript is a lead, never a finding: an admin route in the bundle is only a finding when you call its API and the server answers; a key in the source is only a finding when you show what it unlocks. Prefer source maps over minified guessing, quote file:line, and always pair a client-side discovery with the server request that proves or disproves it. Report unverified keys as leads, explicitly labelled.
|