Fp Check

TL;DR

• 目的：误报交叉验证门禁：用第二工具独立复现候选发现（如 Burp 报了 SQLi 则用 sqlmap/curl 复测），双确认才可写报告。
• 适用：验证/防误报 — 在写报告前必须执行
• 输入：候选 POC + 工具列表（sqlmap / Burp / curl / nuclei）
• 输出：第二工具的验证证据（截图 + 请求响应 + 时间差）
• 红线：仅验证不修复；只报告双工具确认的发现
• 关联：上游：任意 hunt-* / component-nday → 下游：skills/qa/second-opinion → templates/* 报告

When to Use

• Target presents indicators of the vulnerability class this skill covers
• Fingerprint or recon indicates the relevant technology stack is in use
• Authorized testing scope covers the target endpoint or component
• Findings need to be validated through this skill's methodology

When NOT to Use

• Target is clearly outside this skill's scope (refer to related skills)
• No authorization for testing
• Need a different category of testing (use related skills)

Workflow

1. Identify finding — From a previous skill (hunt-sqli, hunt-xss, etc.)
2. Choose second tool — Use different tool than the one that found it
3. Re-run payload — Manual replay with curl or different scanner
4. Compare evidence — Match status code, response marker, timing
5. Document — Capture both tool outputs for report
6. Decide — Report if both tools confirm, else mark as inconclusive

Validation Matrix

False-Positive Killers

• WAF blocking — Real payloads return 403 but tool reports vuln
• Time-based false positive — Network jitter mimics SQLi delay
• Out-of-scope endpoint — Tool reports vuln on subdomain not in scope
• Self-XSS — Only the reporter can trigger
• Clickjacking with X-Frame-Options — Tool reports but headers block