0 Fork 0

mirror of https://github.com/CyberSecurityUP/NeuroSploit.git synced 2026-09-30 13:09:36 +02:00

Files

T

CyberSecurityUPandClaude Opus 4.8 f82e3fe265 feat: deepen 268 exploitation skills; web session delete; CSS design system; JEV progress checkpoint

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>

2026-09-26 16:25:58 -03:00

2.4 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

chains_from: [an open redirect / SSRF / path-traversal on the real host that made a jku/x5u allowlist bypassable]
Chaining hooks: arbitrary token minting → auth bypass / account takeover / privileged API access for downstream steps; the server-side fetch you triggered may itself be an SSRF primitive.

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.4 KiB Raw Blame History