API漏洞利用证明器

---
name: api-exploit-prover
description: Convert API vulnerability leads into confirmed impact or cleanly disproven outcomes with reproducible evidence.
---

# API Exploit Prover

## When To Use
Use this after discovery identifies candidate API weaknesses.

## Inputs
- `candidate_findings`
- `target_base_url`
- `auth_and_role_context`
- `test_data_or_seed_objects`
- `constraints` (noise limits, forbidden write actions)

## Confidence Model
- `C0`: hypothesis only
- `C1`: suspicious signal
- `C2`: reproducible behavior anomaly
- `C3`: exploit primitive proven
- `C4`: business impact proven

## Execution Workflow
### Phase 1: Reproduction Baseline
1. Replay original request as control.
2. Capture stable baseline across repeated requests.
3. Validate request preconditions (auth, ownership, object existence).

### Phase 2: Alternative Technique Check
1. Re-test with a different method than original lead.
2. Vary payload shape and transport encoding.
3. Confirm behavior survives minor variance.

### Phase 3: Impact Escalation
1. Attempt controlled state change or unauthorized data access.
2. Test cross-tenant and cross-role boundaries where legal.
3. Validate whether impact persists after session/token refresh.

### Phase 4: Confounder Elimination
1. Rule out caching and stale object state.
2. Rule out test-environment race artifacts.
3. Rule out expected business behavior incorrectly interpreted as vulnerability.

### Phase 5: Classification
1. `confirmed` only when exploit and impact are replayable.
2. `disputed` when mitigation or expected behavior is proven.
3. `inconclusive` when blockers prevent decision.

## Technique Rules by Vulnerability Type
| Type | Rule |
|---|---|
| BOLA/BFLA | Must show unauthorized object or action with foreign identifier |
| Injection | Must show parser/engine effect beyond literal handling |
| Mass assignment | Must show unauthorized field control and persisted impact |
| SSRF | Must prove outbound request/control over target or metadata access |
| Rate abuse | Must show bypass of intended limit with practical impact |

## Evidence Requirements
- Exact request and response pairs.
- Reproduction count and variance notes.
- Auth role used in each attempt.
- Clear impact statement tied to observable effect.

## Output Contract
```json
{
  "confirmed_findings": [],
  "disputed_findings": [],
  "inconclusive_findings": [],
  "evidence": [],
  "confidence": []
}
```

## Failure Modes
- Single-shot confirmation without retest.
- Treating error differences as exploit proof.
- Claiming impact without business-context validation.

## Exit Criteria
- Every finding has final status and explicit reason.
- Confirmed findings include replayable impact proof.
- Inconclusive findings list unblockers.

## Detailed Operator Notes
### Reproducibility Standard
- Replay each confirmed case in a fresh session.
- Replay with at least one payload or transport variant.
- Keep one negative control request for every positive claim.

### False-Positive Controls
- For timing signals, compare against matched control payloads.
- For authz signals, verify with ownership-correct and ownership-incorrect objects.
- For parser signals, verify semantic effect, not just error shape changes.

### Severity Calibration Inputs
- Required attacker privilege.
- Cross-tenant or single-tenant impact.
- Ability to automate at scale.
- Degree of data sensitivity.

### Reporting Rules
- Include exact request signatures (method, path, key headers, payload hash).
- Include verification run count and consistency notes.
- Include why alternative explanations were rejected.

## Conditional Decision Matrix
| Condition | Action | Evidence Requirement |
|---|---|---|
| Endpoint undocumented but reachable | Add to inventory and prioritize authz checks | request/response baseline + auth behavior |
| Auth behavior inconsistent across methods | Split tests by method and content type | per-method status + body signatures |
| Time-based anomaly only | run matched control timing series | repeated control/test timing traces |
| Object access differs by role | escalate to cross-tenant/cross-role checks | role-tagged replay proof |
| Validation differs by parser | run semantic-equivalent content-type tests | parser-path differential evidence |

## Advanced Coverage Extensions
1. Add negative-object tests for soft-deleted or archived resources.
2. Add replay-window tests for idempotency and duplicate processing.
3. Add bulk endpoint abuse tests for partial authorization failures.
4. Add asynchronous job handoff checks for stale permission snapshots.
5. Add pagination/filter abuse checks for hidden data exposure.