Web Exploit Prover

Purpose

Convert initial web vulnerability leads into high-confidence exploit outcomes.

Inputs

• initial_findings

• target_context

• auth_and_role_data

• environment_constraints

Evidence Levels

• L1

  : suspicious behavior only

• L2

  : exploit primitive observed

• L3

  : code path executed in attacker-controlled way

• L4

  : business impact demonstrated

Workflow

Phase 1: Independent Reproduction

1. Reproduce lead with alternate technique.
2. Validate preconditions and dependencies.
3. Confirm baseline-control difference.

Phase 2: Impact Demonstration

1. Move from primitive to measurable impact.
2. Demonstrate confidentiality, integrity, or authorization breach.
3. Capture minimal proof with clear stop condition.

Phase 3: Robustness Testing

1. Re-test across fresh session and role context.
2. Re-test with slight payload and transport changes.
3. Downgrade confidence on instability.

Phase 4: Final Classification

1. confirmed

   when L3+ is reproducible.

2. plausible

   when primitive exists but impact blocked.

3. disputed

   when mitigation is proven.

4. inconclusive

   when environmental blockers remain.

Output Contract

{
  "confirmed_exploits": [],
  "plausible_findings": [],
  "disputed_findings": [],
  "inconclusive_findings": [],
  "impact_evidence": []
}

Constraints

• No severity inflation from weak indicators.
• Distinguish security mitigation from test-environment failure.

Quality Checklist

• Impact, not just signal, is demonstrated.
• Confirmation uses independent method.
• Confidence aligns with stability.

Detailed Operator Notes

Evidence Ladder

• Step 1: suspicious signal.
• Step 2: primitive confirmation.
• Step 3: execution/authorization breach.
• Step 4: concrete business impact.

Variant Discipline

• Keep payload families grouped by hypothesis.
• Stop variant expansion when new runs are non-informative.
• Prefer context-correct payloads over generic sprays.

Confounder Controls

• Re-test in a fresh session and new object state.
• Re-test with baseline payload and expected-secure payload.
• Confirm that edge cache/CDN behavior is not driving the result.

Reporting Rules

• Include case-level timeline from trigger to impact.
• Include exploitation preconditions and limitations.
• Include clean retest steps for independent validation.

Quick Scenarios

Scenario A: Authorization Drift

• Baseline with owned resource.
• Replay with foreign resource identifier.
• Repeat with role shift and fresh session.
• Confirm read/write/delete differences.

Scenario B: Input Handling Weakness

• Send syntactically valid control payload.
• Send semantically malicious variant.
• Verify parser or execution side effect.
• Re-test with content-type variation.

Scenario C: Workflow Bypass

• Execute expected state sequence.
• Attempt out-of-order transition.
• Attempt repeated action replay.
• Confirm server-side state enforcement.

Conditional Decision Matrix

Condition	Action	Evidence Requirement
Finding signal unstable	downgrade confidence and add retest plan	repeated run variance log
Chain link missing prerequisite	split chain and mark dependency blocker	prerequisite graph
Impact appears low in isolation	evaluate chain amplification paths	chain-level impact narrative
Mitigation claim is partial	verify alternate path and state variants	mitigation bypass check
Environment blocker dominates	classify inconclusive with unblock requests	blocker evidence

Advanced Coverage Extensions

1. Add attack-path branching for multiple privilege starting points.
2. Add defender-detection assumptions and likely monitoring signals.
3. Add rollback/cleanup verification after proof steps.
4. Add business-impact mapping to concrete assets and workflows.
5. Add reproducibility score based on run-to-run consistency.