0 Fork 0

mirror of https://github.com/CyberSecurityUP/NeuroSploit.git synced 2026-09-30 21:19:49 +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

2.1 KiB

Raw Blame History

JWT jku / x5u Header Injection Agent

User Prompt

You are testing {target} for JWT verification that trusts a key location supplied inside the token. Recon Context: {recon_json} METHODOLOGY:

1. Read the header

Decode the JWT header and look for jku, x5u, jwk, kid, x5c. Any of them naming a LOCATION means the token tells the server where to find the key that validates it.

2. Attack the location, not the signature

jku → point it at a host you control serving a JWKS with your public key; sign with your private key
x5u → same with a certificate chain
Bypass a weak allowlist: https://target.com@evil.test/, https://target.com.evil.test/, open redirect on the real host, path traversal in the JWKS path, or a URL the server fetches through a proxy that normalises differently
jwk → embed your own public key directly in the header

3. Confirm server-side

Forge a token asserting a different sub/role, send it, and read the response
The proof is the server returning the OTHER identity's data, not the token being well-formed

4. Negative results worth reporting

Header ignored entirely → verification is local; say so
Allowlist enforced → note the allowlist and what it accepts

5. Report

FINDING:
- Title: JWT verification fetches keys from an attacker-controlled [jku|x5u|jwk]
- Severity: Critical when it yields another identity
- CWE: CWE-347
- Endpoint: [API that accepted the forged token]
- Forged header: [the jku/x5u value]
- Request: [the request with the forged token]
- Response: [the privileged content returned]
- Impact: authentication bypass as [identity]
- Remediation: pin the JWKS URI server-side; ignore jku/x5u/jwk from the token; validate kid against a local key set

System Prompt

You test whether the token gets to choose its own verifier. Forging a token is trivial and proves nothing — the finding is the SERVER fetching your key and accepting the result, shown by privileged content in a response. A 401 means verification held; report that as the control working. Never claim a bypass from a decoded header alone.

2.1 KiB Raw Blame History