mirror of
https://github.com/CyberSecurityUP/NeuroSploit.git
synced 2026-09-30 13:09:36 +02:00
CyberSecurityUPandClaude Opus 4.8
f82e3fe265
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>
47 lines
3.9 KiB
Markdown
47 lines
3.9 KiB
Markdown
# 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 actually gates
|
|
- Register a fresh account and, while UNVERIFIED, walk every authenticated surface: web routes AND the raw API (from `/openapi.json`, JS bundle, or a captured session). The gate is frequently only on the login page or a UI banner, while the API accepts the session token directly.
|
|
- Record the state machine: signup -> token email -> `/verify?token=...`. Capture the verify request and the `verified=true` transition.
|
|
|
|
### 2. Bypass attempts (concrete)
|
|
- API-direct: replay the unverified session's bearer/cookie against sensitive endpoints (`GET /api/me`, `POST /api/orders`, invite/share). Does it work without the verified flag?
|
|
- Self-set flag: does the register/profile response or a `PATCH /api/user {"emailVerified":true}` / mass-assignment let you flip it? (Chain to mass-assignment agent.)
|
|
- Email-change-after-verify: verify, then change email to a new address; if the account stays `verified` for the NEW unverified address, that is the bypass.
|
|
- Address normalisation collisions (pre-ATO): register the victim's address in a form that normalises to theirs — `victim+x@`, dot-variants for Gmail (`v.ictim@`), trailing dot, unicode homoglyphs, case, IDN. Show BOTH addresses resolving to ONE account.
|
|
- Token weaknesses: is `token` guessable/sequential, reusable, missing expiry, or does it verify whatever email is in the REQUEST rather than the one it was issued for? Try swapping the email param while keeping a valid token.
|
|
- SSO/social join: log in via a provider that returns an unverified email and see if it merges into an existing local account without proof.
|
|
|
|
### 3. Why it matters (test, don't assume)
|
|
- Pre-account-takeover: create the victim's address unverified now; when they later sign up (esp. via SSO), do you retain access or merge into their account?
|
|
- Trust escalation: does an unverified account receive invites, shares, internal-domain (`@company.com`) auto-join, or team privileges?
|
|
|
|
### 4. Prove
|
|
- Show the UNVERIFIED session performing an action the product states requires verification — full request + success response.
|
|
- For email-change: show the account reading verified-only content under the new, never-verified address.
|
|
- For normalisation: show the two distinct-looking addresses mapping to a single account id.
|
|
|
|
### 5. Pitfalls / false-positives
|
|
- "The email was never verified" alone is NOT a finding — the finding is the action the server allowed.
|
|
- A UI that hides features but whose API still enforces the check on the server = not a bypass; confirm the SERVER accepted the action.
|
|
- Verification link working twice may be by design (idempotent) unless it re-activates a disabled account.
|
|
|
|
### 6. 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. Keep it benign: use your own controlled addresses and sessions, never a real user's mailbox.
|