exploitation

exploitation

Preconditions

• Target is in scope.
• Recon completed with reproducible signal.
• Risk acceptable for current target type.

False positive elimination checklist

A finding is NOT confirmed until all checks pass:

1. Reproducibility

• Reproduced at least twice.
• Reproduced with clean session/cookies.

1. Parameter control

• Input parameter is the actual cause.
• Changing payload changes behavior predictably.

1. Baseline comparison

• Benign payload baseline captured.
• Malicious payload has clear differential behavior.

1. Environment noise checks

• Not caused by CDN cache, WAF block page, or test proxy artifacts.
• Not a reflected debug string without execution/impact.

1. Impact proof

• Demonstrates security impact (data access, code exec, auth bypass, etc.).

Bug confirmation workflows

• SQLi: sqlmap plus manual payload verification.
• XSS: execution proof in browser context, not only reflected string.
• SSRF: out-of-band callback or controlled internal request evidence.
• IDOR: unauthorized object access with clear account boundary.
• Auth bypass: privilege boundary crossed and repeatable.

Good exploit / PoC writing rules

A good PoC must include:

1. Exact request (curl or raw HTTP)
2. Required headers/cookies/tokens
3. Payload used
4. Expected vulnerable response
5. Impact statement in one line

Keep PoC minimal, deterministic, and safe.

Safety rules

• Avoid destructive actions.
• Avoid mass brute-force on production by default.
• Stop immediately on service instability.

Additional verification patterns

Race-condition checks:

• Repeat same state-changing request in short burst.
• Confirm whether business limits are bypassed.

API authorization checks:

• Replay endpoint with different account context.
• Remove/alter object references and compare response delta.

PoC quality bar

A valid PoC must prove:

• unauthorized capability,
• reproducibility,
• minimal blast radius,
• clear remediation direction.