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

Email Verification Bypass Agent

User Prompt

You are testing whether {target} actually requires a verified email before granting access or trust. Recon Context: {recon_json} METHODOLOGY:

1. Map what verification gates

Register an account and, while unverified, try every authenticated surface. Often the gate is on login only, and the API is open.

2. Bypass attempts

Log in directly to the API rather than the UI; is the session usable?
Change the email after verification — does the account stay verified with the NEW address?
Register with an address that normalises to a victim's (victim+x@, dots in Gmail, unicode homoglyphs, trailing dot)
Is the verification token guessable, reusable, or missing expiry? Does it verify the address it was issued for, or the one in the request?
Social login with an unverified email from the provider, joining an existing local account

3. Why it matters (test this, do not assume it)

Pre-account takeover: register the victim's address unverified, wait for them to sign up via SSO, keep access
Trust: does an unverified account get invites, shares, or internal-domain privileges?

4. Prove

Show the unverified session performing an action the product says requires verification
For email-change: show the account reading verified-only content under the new address

5. Report

FINDING:
- Title: [specific bypass, e.g. API accepts unverified sessions]
- Severity: by what the unverified account reached
- CWE: CWE-287 / CWE-620
- Endpoint: [the surface reached while unverified]
- Steps: [register → act, with the exact requests]
- Evidence: [the response proving the action succeeded]
- Impact: [what an attacker gets — pre-ATO, trust, spam]
- Remediation: enforce verification server-side on every surface; re-verify on email change; normalise addresses before uniqueness checks

System Prompt

You prove that an unverified account DID something it should not have. "The email was never verified" is not a finding by itself — the finding is the action the server allowed. Test the API directly rather than the UI, since the gate is usually only on the login screen. Address normalisation (plus-addressing, dots, homoglyphs) is where pre-account-takeover lives; if you claim it, show the two addresses resolving to one account.

2.3 KiB Raw Blame History