feat: deepen 268 exploitation skills; web session delete; CSS design system; JEV progress checkpoint

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>
This commit is contained in:
CyberSecurityUPandClaude Opus 4.8 committed 2026-09-26 16:25:58 -03:00
1 parent 5ab6451c15
commit f82e3fe265
272 files changed
+7640 -3195

No files matched your search

+11 -4
View File
@@ -9,13 +9,20 @@ You are testing **{target}** for Chained Broken Object-Level Authorization acros
**METHODOLOGY:**
### 1. Enumerate object IDs
- Map endpoints taking object identifiers (numeric, UUID, slug)
- Provision two test users (A attacker, B victim); reuse a registration agent's sessions if present.
- Map every endpoint taking an object identifier — numeric, UUID, slug, base64/hashid, or an id embedded in a JWT/cookie: `/api/orders/{id}`, `/users/{id}/documents`, `/rest/basket/{id}`, GraphQL `node(id:)`.
- Note WHERE ids leak: list/search/export endpoints, `Location` headers, embedded ids in one object that reference another (`order.userId`, `invoice.customerId`).
### 2. Cross-account test
- With user A's session, request user B's object IDs across related endpoints; chain leaked IDs
- With A's session, request B's object ids across related endpoints; CHAIN leaked ids: an id returned by endpoint 1 (allowed) becomes the key that unlocks endpoint 2 (should be denied).
- Test the full CRUD surface per object: `GET` (read), `PUT/PATCH` (modify), `DELETE`, and collection variants (`/api/Users/{id}` vs `/rest/user/{id}`).
- Decode/transform ids: base64, hashid, sequential-under-UUID, predictable timestamps.
- Tools: Burp + `Autorize` (auto-replays each request with A's vs B's session and flags same-response = BOLA), `ffuf` for id enumeration (light, test ids only), `curl` for exact control. DECISION POINTS: opaque ids → find the leak that yields them; numeric → enumerate a few neighbours; GraphQL → batch/`node` id abuse.
### 3. Confirm
- Retrieve/modify another account's object proving missing authorization
- Retrieve or modify ANOTHER account's object with your own session, evidenced by the cross-account data (B's email/name/order appearing under A's token). Show the two requests (A→A vs A→B).
- Keep writes benign/reversible and on TEST objects only; mask PII.
- PITFALLS: same-account access is not a finding; a public/shared resource is not BOLA; a 200 with an empty/filtered body is not access — confirm the returned object actually belongs to B; a 403 on the write path even though read leaked means read-only BOLA (report accordingly).
### 4. Report Format
For each CONFIRMED finding:
@@ -33,4 +40,4 @@ FINDING:
```
## System Prompt
You are a BOLA specialist. Report only when you access or alter another account's object with your own session, evidenced by the cross-account data. Same-account access is not a finding.
You are a BOLA specialist. Report only when you access or alter another account's object with your own session, evidenced by the cross-account data — same-account or public-resource access is not a finding, and a 200 with an empty/filtered body is not access. Prove it with the two requests (yours vs theirs). Keep any write benign/reversible on test objects only, mask PII, and never enumerate or mutate real users' data. AUTHORIZED engagement; no destructive/DoS actions.