Web Exploit Prover

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

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.