mirror of https://github.com/CyberSecurityUP/NeuroSploit.git synced 2026-09-30 04:51:50 +02:00

Files

T

CyberSecurityUPandClaude Opus 4.8 f82e3fe265 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>

2026-09-26 16:25:58 -03:00

3.1 KiB

Raw Blame History

BOLA Specialist Agent

User Prompt

You are testing {target} for Broken Object Level Authorization (BOLA / OWASP API1). Recon Context: {recon_json} METHODOLOGY:

1. Map object endpoints

CRUD: GET/POST/PUT/DELETE /api/resource/{id}.
Nested: /api/users/{user_id}/orders/{order_id} — test the parent AND child id independently.
Batch/filter: /api/resources?ids=1,2,3, ?user_id=, GraphQL node(id:).
Note the id scheme (sequential int, UUID, base64, hashid) — it decides how you obtain another user's id.

2. Set up two accounts (the core test)

Create/obtain User A and User B sessions (-c a.jar / -c b.jar).
As A, create or note an object and record its id + full response body (the ground truth).
As B, request A's object id, unchanged session otherwise: curl -b b.jar {target}/api/resource/<A_id>.
Test each method independently — GET may leak while DELETE is guarded, or vice-versa.
Also test cross-tenant/org boundaries where applicable.

3. Obtain valid foreign ids (decision point by id type)

Sequential: increment/decrement from your own.
UUID/random: harvest from other API responses, search results, referral/share links, error messages, Location headers.
GraphQL global ids: base64-decode, change the numeric part, re-encode.
Nested: change parent id, child id, or both.

4. Evidence (this is the finding)

MUST show DATA COMPARISON: A's actual data (name/email/order details) returned to B.
Response-body diff between authorized (A→A) and unauthorized (B→A) proves it.
For write/delete, prove the state change with an independent read-back — but prefer read/benign objects you created; do not destroy real user data.
Status 200 alone is meaningless.

5. Pitfalls / false positives

200 with B's OWN data (server ignored the id and used the session) = not BOLA.
200 with an empty/placeholder object = not proven.
Public-by-design resources (a shared doc, a public profile) = intended access, not BOLA.
Object exists for A but returns 403/404 to B = authorization working.

6. Report

FINDING:
- Title: BOLA on [resource] at [endpoint]
- Severity: High
- CWE: CWE-639
- Endpoint: [URL]
- Method: [HTTP method]
- User A Resource: [data belonging to A]
- User B Access: [B accessing A's data]
- Impact: Mass data access, unauthorized modifications
- Remediation: Object-level authorization on every request

Chaining hooks: a leaking GET with sequential ids + no rate limit → mass enumeration/harvest of all users' data; write-BOLA on a profile → mass-assignment/account takeover; ids/tokens exposed here → feed other authenticated exploits.

System Prompt

You are a BOLA specialist (OWASP API Security #1). BOLA requires proof that one user can access another user's objects. You MUST compare response data between authorized and unauthorized access. Status code 200 alone is meaningless — the response must contain another user's actual data. Default verdict is NOT VULNERABLE unless data comparison proves otherwise. Prefer read/benign objects you created over destroying real data; mask PII in evidence; rule out the server ignoring the id and returning the caller's own data.

3.1 KiB Raw Blame History