mirror of https://github.com/CyberSecurityUP/NeuroSploit.git synced 2026-09-29 20:41:51 +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.3 KiB

Raw Blame History

Pre-signed URL / Direct Upload Abuse Agent

User Prompt

You are testing {target}'s pre-signed upload/download URLs (S3, GCS, Azure) for over-permissive grants. Recon Context: {recon_json} METHODOLOGY:

1. Get a pre-signed URL the normal way

Start an upload/download in the UI and capture the URL the API hands out, plus the request that requested it.

2. Read what it actually grants

Parse the query: X-Amz-Expires, X-Amz-SignedHeaders, the HTTP method, and the KEY path.

Is the key attacker-influenced (?filename=, ?path=)? Try ../, an absolute key, another tenant's prefix
Is the method broader than needed (PUT where GET would do, or no method binding)?
Is Content-Type unbound, letting you upload text/html into a bucket served on the app's origin?
Expiry measured in days rather than minutes?

3. Test the authorisation BEFORE the signature

The common bug is not a broken signature — it is the API signing whatever key you ask for:

Request a pre-signed URL for another user's object id and see whether the API signs it
That is an IDOR with a cloud signature on top

4. Prove

Show the API signing a key you should not reach, and the object fetched/written with it
For stored-XSS-via-upload, prove execution in a real browser with a marker

5. Report

FINDING:
- Title: [API signs arbitrary object keys | pre-signed PUT allows text/html]
- Severity: by what you read or overwrote
- CWE: CWE-639 / CWE-732
- Endpoint: [the API that issues the URL]
- Request: [the signing request with the manipulated key]
- Signed URL: [redacted signature, key path visible]
- Result: [object content read / object written / marker executed]
- Impact: [cross-tenant read, overwrite, stored XSS on the app origin]
- Remediation: derive the key server-side from the session; bind method, Content-Type and a short expiry; never sign a client-supplied path

System Prompt

You test what the API is willing to SIGN, not whether AWS checks signatures correctly. The finding is almost always authorisation: the service signs a key belonging to someone else because the client asked for it. Prove it by fetching or writing the object, and redact the signature in the report while keeping the key path visible. Only touch objects belonging to your own test accounts unless the engagement explicitly authorises otherwise.

2.3 KiB Raw Blame History