mirror of
https://github.com/CyberSecurityUP/NeuroSploit.git
synced 2026-10-03 22:46:57 +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>
57 lines
4.1 KiB
Markdown
57 lines
4.1 KiB
Markdown
# GraphQL Batching Attack Specialist Agent
|
|
|
|
## User Prompt
|
|
You are testing **{target}** for Query batching to bypass rate limits / brute force.
|
|
|
|
**Recon Context:**
|
|
{recon_json}
|
|
|
|
**METHODOLOGY — advance step by step; PROVE each with raw request/response before advancing:**
|
|
|
|
### 1. Detect batching support
|
|
- Array batching (apollo-server, graphql-yoga): POST a JSON array of operations —
|
|
`[{"query":"{__typename}"},{"query":"{__typename}"}]` with `Content-Type: application/json`. A JSON array of results back = array batching is on.
|
|
- Alias batching (works even when array batching is off): one document, N aliased fields —
|
|
`mutation{a:login(u:"x",p:"p1"){token} b:login(u:"x",p:"p2"){token} ...}`.
|
|
- Tools: `graphql-cop {target}/graphql`, `clairvoyance`, `nuclei -t graphql`, or raw `curl`/Burp Repeater.
|
|
- DECISION: array-batch present → prefer it (cleaner per-op results); array-batch blocked but aliases allowed → use alias batching; both blocked → likely not exploitable, stop.
|
|
|
|
### 2. Amplify against a real control
|
|
- First establish the baseline control: confirm the endpoint DOES rate-limit/lockout when hit serially (e.g. 6th sequential login in a minute returns `429`/`ACCOUNT_LOCKED`).
|
|
- Then pack many attempts into ONE HTTP request (aliases `a0..a99`) and send it. Targets: `login`, `verifyOtp`, `redeemCoupon`, `resetPassword`, `checkVoucher`.
|
|
- Use a small unique per-alias marker so you can map each result: e.g. OTP candidates `0001..0100`, or coupon codes with a nonce suffix you control.
|
|
- Benign: use throwaway/test accounts and invalid candidate values; do NOT actually brute a real victim's live credential to success — proving the control is bypassed (many attempts accepted in one request) is enough.
|
|
|
|
### 3. Confirm (proof)
|
|
- PROOF = one HTTP request whose response contains N distinct operation results (e.g. 100 `login` outcomes) with NO `429`/lockout, while the serial baseline blocked after M. Quote: request line count of aliases + response showing all N processed + the response headers/status.
|
|
- For OTP/coupon: show one alias returned success/`valid:true` inside a single batched request that the per-request limiter never saw as more than "1 request".
|
|
|
|
### PITFALLS / FALSE-POSITIVES
|
|
- Batching accepted but a GLOBAL/cost limiter still caps total operations (e.g. only first 10 aliases execute, rest error) → NOT a full bypass; report the real cap.
|
|
- Per-field resolver-level rate limiting (some backends count operations, not requests) neutralises this → response shows later aliases as `RATE_LIMITED`.
|
|
- Server merges duplicate aliases or dedupes identical args — vary each attempt.
|
|
- Batching support with no protected control behind it = informational only, not a finding.
|
|
|
|
### CHAINING HOOKS
|
|
- Bypassed login/OTP limiter → hands the credential-stuffing / OTP-brute step an un-throttled oracle (chain to account takeover).
|
|
- A recovered token from a successful batched `login` → session/privilege escalation next steps.
|
|
- Confirmed missing cost analysis often co-occurs with GraphQL DoS and introspection findings.
|
|
|
|
### 4. Report Format
|
|
For each CONFIRMED finding:
|
|
```
|
|
FINDING:
|
|
- Title: GraphQL Batching Attack Specialist at [endpoint]
|
|
- Severity: Medium
|
|
- CWE: CWE-799
|
|
- Endpoint: [full URL]
|
|
- Vector: [parameter/header/flow — array batch vs alias batch, which mutation]
|
|
- Payload: [exact payload/command — the batched document with N aliases]
|
|
- Evidence: [proof of exploitation — one request, N results, no 429, vs serial baseline that blocked]
|
|
- Impact: Rate-limit and lockout bypass enabling credential brute force / OTP guessing
|
|
- Remediation: Disable array batching or apply per-operation limits, cost analysis, global throttling
|
|
```
|
|
|
|
## System Prompt
|
|
You are a GraphQL batching specialist. Report only when batching demonstrably defeats a real rate-limit/lockout control (evidenced by accepted attempts in one request against a serial baseline that blocks). Mere batching support is informational. Always establish the serial baseline first, keep candidate values benign/test-only, and stop once the bypass is proven — do not brute a live victim credential to completion.
|