berrinche699/BBRecon-Methodology

# BBRecon 方法论 **真实的 Bug Bounty 方法论——基于真实的项目经验，而非纸上谈兵。** 这里的一切都来自实际的活跃项目：什么有效，什么被标记为 N/A，原因是什么，以及如何在提交前区分它们。 配套工具：[BurpRecon](https://github.com/berrinche699/BurpRecon) ## 目录 | # | 主题 | 解决的核心问题 | |---|-------|-----------------------| | [01](./01-recon/) | Recon & Burp XML 分析 | 如何在 5 分钟内处理 1500+ 个请求 | | [02](./02-idor-bola/) | IDOR / BOLA 评估 | 数字 ID 什么时候才真正可利用？ | | [03](./03-auth-flows/) | Auth 流程 & JWT 攻击 | Host Header Injection：真阳性 vs 误报 | | [04](./04-waf-cdn/) | WAF / CDN 检测 | 为什么 Python 会收到 403 而 Burp Repeater 不会 | | [05](./05-open-redirect/) | Open Redirect 有效性 | 重定向参数什么时候才真正有意义？ | | [06](./06-reporting/) | 报告 & Triage | 如何写出一份不会被作为 N/A 关闭的报告 | ## 核心原则 **1. 没有 PoC = 没有报告。** 如果你无法逐步重现它，就不要提交。Triage 会将其关闭，你的 signal score 也会下降。 **2. 是影响决定严重程度，而不是技术。** `/api/users/{id}/preferences` 上的 IDOR 与 `/api/users/{id}/bank-accounts` 上的 IDOR 是不同的。相同的模式，严重程度却完全不同。 **3. 理解控制存在的原因。** IDOR 目标上的 403 并不是死胡同——它是一个信号，表明 ACL 是在服务端实现的。在放弃之前，使用来自不同账户的第二个已认证 session 进行测试。 **4. WAF 不是安全。** Akamai、Cloudflare 和 F5 拦截了你的 Python 脚本，并不意味着 endpoint 是受保护的。它只意味着传输层受到了保护。漏洞可能仍然存在——请通过 Burp Repeater 进行测试。 **5. 误报浪费大家的时间。** 一份 N/A 报告对你声誉的损害超过了五份有效报告带来的帮助。这套方法论的重点在于，以发现漏洞的速度同样快地排除无效项。 ## 快速决策树 ### 这个 IDOR 值得测试吗？ ``` Numeric ID in path? ├── No → not IDOR (check UUID/entropy section) └── Yes → What is the HTTP method & status code? ├── GET + 200 → CRITICAL — test immediately with second session ├── POST/PUT/PATCH/DELETE + 2xx/201/204 → HIGH — write/delete on other user's data ├── GET + other 2xx → MEDIUM — unclear impact, confirm data ownership └── 4xx? ├── 403 → ACL enforced, skip unless you have role escalation └── 404 → ID is the object key → POTENTIAL, test with second session ``` ### 这个 Host Header Injection 有效吗？ ``` Endpoint sends emails? (reset, OTP, invite, verify) ├── No → not exploitable via HHI (no email poisoning possible) └── Yes → Does it use Host header to build the link in the email? ├── No → FP — the URL is hardcoded server-side └── Yes → Is there a cache in front? (Via, X-Cache, CF-Cache) ├── No → Password Reset Poisoning only (still High) └── Yes → Web Cache Poisoning possible → Critical ``` ### 这个 Open Redirect 有效吗？ ``` Does the redirect param control where the browser goes? ├── No (reflected but not followed) → FP └── Yes → Does it escape the origin domain? ├── No (same domain only) → Low/Info └── Yes → Is it used post-auth? (login?next=, OAuth redirect_uri) ├── Yes → High (token/session theft possible) └── No → Medium (phishing vector) ```

标签：Bug Bounty, CISA项目, Modbus, Web安全, 可自定义解析器, 安全测试方法论, 漏洞报告, 蓝队分析, 防御加固