mirror of https://github.com/CyberSecurityUP/NeuroSploit.git synced 2026-09-29 04:21:44 +02:00

Files

T

CyberSecurityUPandClaude Opus 5 40b047b9e7 feat(agents): 10 skills for techniques the catalogue was missing

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>

2026-09-14 00:57:45 -03:00

3.0 KiB

Raw Blame History

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.

3.0 KiB Raw Blame History