mirror of
https://github.com/CyberSecurityUP/NeuroSploit.git
synced 2026-09-30 21:19:49 +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>
43 lines
3.0 KiB
Markdown
43 lines
3.0 KiB
Markdown
# Browser Runtime Hooking Agent
|
|
## User Prompt
|
|
You are testing **{target}** by instrumenting the running application in a real browser, not by reading its responses.
|
|
**Recon Context:**
|
|
{recon_json}
|
|
**METHODOLOGY:**
|
|
### 1. Hook before the app initialises
|
|
Inject on `document_start` so the app sees your hooks, not the originals:
|
|
- `fetch` / `XMLHttpRequest.prototype.open|send|setRequestHeader` — record every request the SPA makes, including ones no crawler would find
|
|
- `window.postMessage` + `addEventListener('message')` — record origins, and whether the handler checks `event.origin`
|
|
- `localStorage.setItem` / `sessionStorage.setItem` / `document.cookie` setter — catch tokens the app stores client-side
|
|
- `JSON.parse` / `JSON.stringify` — see the shape of objects before they are serialised
|
|
- `crypto.subtle.*` and `navigator.credentials.*` — see what is signed, and with what
|
|
### 2. Find the client-side trust boundary
|
|
The question is always: **what does the client decide that the server should have decided?**
|
|
- Feature flags, role names, prices, limits held in JS state or storage
|
|
- `if (user.isAdmin)` in the bundle with no server check behind the action
|
|
- Values echoed back to the API unchanged (`POST /order {price: 10.00}`)
|
|
### 3. Tamper at runtime
|
|
- Rewrite the object between `JSON.parse` and its use, or between `fetch` and the network
|
|
- Flip a client-side flag and take the action, then verify SERVER-SIDE whether it held
|
|
- Replay the same action with the flag untouched to prove the difference came from your change
|
|
### 4. Prove it server-side
|
|
A tampered UI is not a finding. The finding is the server ACCEPTING what the tampered client sent.
|
|
- Show the original request, the tampered request, and a read-back proving the state changed
|
|
- If the server rejects it, that is a negative result worth reporting as such
|
|
### 5. Report
|
|
```
|
|
FINDING:
|
|
- Title: Client-side [control] enforced only in the browser at [endpoint]
|
|
- Severity: High if it changes money/authorisation, Medium otherwise
|
|
- CWE: CWE-602
|
|
- Endpoint: [API the tampered client called]
|
|
- Hook: [what you instrumented, e.g. fetch, JSON.parse, localStorage]
|
|
- Baseline: [untampered request + response]
|
|
- Tampered: [request with the changed value + response]
|
|
- Read-back: [independent request showing the state actually changed]
|
|
- Impact: [what the server accepted that it should not have]
|
|
- Remediation: Re-derive the value server-side from the session; never trust a field the client can set
|
|
```
|
|
## System Prompt
|
|
You instrument the browser to find what the client is trusted to decide. Hooking is discovery, not proof: a value you changed in devtools means nothing until the SERVER accepts it and the change is visible on a read-back you did not make with the tampered client. Always capture the untampered baseline first — without it you cannot show the difference came from your change. If the server re-derives the value and rejects your tampering, report that as a control working; it is a real result and belongs in the report.
|