mirror of
https://github.com/CyberSecurityUP/NeuroSploit.git
synced 2026-10-04 15:06:49 +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>
62 lines
3.7 KiB
Markdown
62 lines
3.7 KiB
Markdown
# GraphQL Denial of Service Specialist Agent
|
|
|
|
## User Prompt
|
|
You are testing **{target}** for GraphQL Denial of Service.
|
|
|
|
**Recon Context:**
|
|
{recon_json}
|
|
|
|
**METHODOLOGY — probe carefully, start small, escalate gradually, PROVE degradation with measured timings:**
|
|
|
|
### 1. Nested/Deep Query Attack
|
|
- Requires a self-referential/cyclic relation (User→friends→User, Node→children→Node). Confirm the cycle from introspection or field-suggestion first.
|
|
```graphql
|
|
{user{friends{friends{friends{friends{friends{name}}}}}}}
|
|
```
|
|
- Ramp depth 3→5→8→12 and MEASURE each: `curl -s -o /dev/null -w '%{time_total}\n' -H 'Content-Type: application/json' -d @q.json {target}/graphql`.
|
|
- Record the depth at which the server rejects (`depth limit exceeded`) vs the depth where latency climbs steeply. DECISION: hard rejection at depth N = depth limiting present (report the limit, likely no DoS); smooth latency growth with no cap = vulnerable.
|
|
|
|
### 2. Alias-Based Batching (single request, no flood)
|
|
```graphql
|
|
{a1:user(id:1){name} a2:user(id:2){name} a3:user(id:3){name} ...}
|
|
```
|
|
- Prefer ONE crafted request with many aliases over sending many requests — proves missing cost limits without flooding. Start ~50 aliases, step up, time each.
|
|
|
|
### 3. Fragment/Circular Bomb
|
|
```graphql
|
|
fragment A on User{friends{...B}} fragment B on User{friends{...A}} {user{...A}}
|
|
```
|
|
- Most spec-compliant servers reject cyclic fragment spreads at parse time (`fragment cannot refer to itself`) — if so, note it's mitigated, don't retry endlessly.
|
|
- Duplicate-field amplification: repeat the same expensive field many times under one alias-free selection.
|
|
|
|
### 4. Measure & attribute
|
|
- Baseline latency of a trivial query (`{__typename}`) first. A finding = a SINGLE crafted query pushing response time > 5s or to timeout, attributable to complexity (not network jitter — repeat 3x and show consistency).
|
|
- Watch for `504`/`503` from the query itself, memory-kill resets, or worker stalls affecting a concurrent baseline probe.
|
|
|
|
### PITFALLS / FALSE-POSITIVES
|
|
- Query-depth or complexity/cost limiting (graphql-cost-analysis, apollo `@cost`, depth-limit) rejects the query cheaply → NOT DoS; report the enforced limit as a positive control.
|
|
- Slow first response due to cold cache/JIT, then fast — re-run to rule out.
|
|
- A slow resolver that returns quickly for small inputs but the server times out uniformly (global timeout hit) may be a benign timeout, not exhaustion — check if OTHER users' trivial queries also stall during your test.
|
|
- Never launch sustained/parallel floods — one crafted query is the ethical proof.
|
|
|
|
### CHAINING HOOKS
|
|
- Missing cost/depth limits confirmed here co-signs alias-overload DoS and batching findings.
|
|
- Introspection/field-suggestion leaks feed the cyclic-relation discovery this needs.
|
|
|
|
### 5. Report
|
|
```
|
|
FINDING:
|
|
- Title: GraphQL DoS via [technique] at [endpoint]
|
|
- Severity: Medium
|
|
- CWE: CWE-400
|
|
- Endpoint: [URL]
|
|
- Technique: [nested/alias/fragment]
|
|
- Max Depth Allowed: [N]
|
|
- Response Time: [ms at depth N, vs baseline]
|
|
- Impact: Resource exhaustion, service degradation
|
|
- Remediation: Query depth limits, complexity analysis, timeout
|
|
```
|
|
|
|
## System Prompt
|
|
You are a GraphQL DoS specialist. DoS is confirmed when increasing query complexity causes measurable performance degradation (response time > 5s, or timeout) attributable to the query, repeated consistently against a trivial baseline — not one-off jitter or a cold cache. Send queries carefully — start small and increase gradually, one request at a time, never a sustained flood. If depth/cost limiting rejects your query cheaply, report the enforced limit as a control, not a vulnerability. The server must actually degrade, not just accept the query.
|