ardakocadoruu/bug-bounty-methodology

## 为什么需要这份指南？ 目前流传的大多数 Bug Bounty 指南都是 2018 到 2020 年间写的。它们并没有错 —— SQLi 依然存在，XSS 依然能赚钱 —— 但攻击面已经发生了根本性的变化。各个项目已经迁移到云原生基础设施、API 优先架构、到处都是 OAuth 2.0，以及现在的 AI/LLM 功能，这些引入了全新的漏洞类别，在两年前根本没有人有相关的检查清单。 那个时期的指南漏掉了： - **AI/LLM 攻击面** —— 提示词注入、模型窃取、RAG 投毒、影响生产系统的越狱攻击 - **云原生目标** —— 针对 IMDSv2 的 SSRF、S3 配置错误链条、IAM 权限提升、GitHub Actions 投毒 - **现代身份验证绕过** —— OAuth 2.0 state 参数攻击、PKCE 降级、JWT 算法混淆、设备流程滥用 - **API 优先应用** —— GraphQL 内省滥用、大规模 REST IDOR、现代框架中的批量赋值 - **供应链攻击角度** —— 依赖混淆、域名抢注（Typosquatting）、影响范围内资产的 npm/PyPI 包劫持 这不是一个带有截图的初学者教程。这是我实际使用的方法论 —— 决策树、工具链、发现高赏金漏洞的思维方式，以及关于什么会浪费你时间的惨痛教训。 ## 思维方式 这一节比任何工具列表都重要。我曾见过拥有完美技术水平的猎人苦熬了几个月都没有获得有意义的赏金，而知识储备只有他们一半的人却能持续斩获 P1 漏洞。这种差异几乎总是思维方式的问题。 ### 像写错代码的工程师一样思考 我发现最有用的心智模型是：想象你是一个在产品发布前的周五晚上 11 点交付这个功能的开发者。你在哪里偷工减料了？你在哪里盲目信任了不该信任的输入？你忘记检查什么了？ 审计员寻找的是对检查清单的违反。猎人寻找的是对意图的违反。代码做了某件事 —— 它是否真的做到了工程师*意图*让它做的事？通常，答案是否定的。 ### 每一个功能都是一个潜在的漏洞 当你看到“与团队成员分享此报告”时，你应该立刻想到：IDOR、 broken access control、邮箱枚举、如果它获取 URL 就会产生 SSRF、如果它渲染内容就会产生存储型 XSS。这并不是因为所有这些都会存在 —— 它们不会 —— 而是因为每个功能都是一台处理输入、做出信任决定并产生输出的机器。这些决定中的每一个都可能是错的。 ### 最好的漏洞在于业务逻辑 扫描器能发现 SQLi、XSS、已知的 CVE。它们发现不了： - “如果我在 API 请求体中直接将我的订阅计划设置为 'enterprise'，它居然接受了” - “在计费周期中途取消订阅并立即重新订阅，可以永久保留付费功能” - “退款 API 不检查支付 ID 是否属于我的账户” - “邀请一个用户加入工作区然后再移除他们，并没有撤销他们的 API token” 这些是赏金高达 $5,000 到 $50,000 的漏洞。它们要求你理解应用程序的业务模型，并推理信任假设在哪里崩塌。任何扫描器都永远找不到它们。 ### 随意扩大范围会毁了项目 阅读范围文档。再读一遍。我曾见过猎人因为测试范围外的资产而被封禁，因为他们认为“公司拥有它，所以它属于范围内”。并不是这样的。范围文档定义了交战规则，违反这些规则 —— 即使是无意中 —— 也会导致你被移出项目、被拒绝支付赏金，或者在极端情况下，引发法律问题。 如果有疑问，就去问。大多数项目都有披露渠道。快速问一句“api-staging.example.com 在范围内吗？”只需 30 秒，却可以挽救你的声誉。 ### 去重现实 假设你的发现已经被报告了。特别是在公开项目中。漏洞越明显，就越有可能在第一周就被二十个其他猎人发现。这就是侦测质量能够区分顶级猎人的原因之一 —— 如果你和其他人测试的是相同的攻击面，你就是在争夺那些重复的漏洞。 解决办法不是走得更快。而是要更深入或换个地方。找到被遗忘的子域名。找到尚未整合到安全项目中的被收购公司。找到 Web 测试人员忽略的移动端 API。 ### 关于耐心和一致性 Bug Bounty 不是买彩票。它是一项具有复利回报的技能。你的第一个月可能会令人沮丧。你的第一年可能只能赚几百美元。年收入 $200k 的猎人已经做了 5 年以上，并建立了花了数年时间开发的剧本、自动化流程和项目关系。请设定切合实际的期望。 ## 快速入门 —— 在 3 小时内找到你的第一个漏洞 这是一个为完全初学者设计的现实路径。不是“按照这些步骤你肯定会找到漏洞” —— 事情不是这样运作的 —— 但这是概率最高的起点。 ### 第 1 步：选择合适的项目（30 分钟） 不要从 Google 或 Apple 开始。他们的项目已经饱和，低垂的果实早就不存在了。 寻找具有以下特征的项目： - **宽泛的范围** —— `*.example.com` 比 `www.example.com` 好得多 - **最近上线** —— 新上线的项目有更新鲜的攻击面 - **未列出响应时间 SLA** —— 意味着竞争较小 - **明确的“范围外”列表很短** —— 操作空间更大 好的起步平台： - [HackerOne](https://hackerone.com/programs) —— 按“公开”过滤，按“最新”排序 - [Bugcrowd](https://bugcrowd.com/programs) —— 类似的过滤条件 - [Intigriti](https://www.intigriti.com/programs) —— 被低估，饱和度较低 - [YesWeHack](https://yeswehack.com/) —— 优质的欧洲项目，不那么拥挤 ### 第 2 步：子域名枚举（45 分钟） ``` # 如有需要先安装工具 go install -v github.com/projectdiscovery/subfinder/v2/cmd/subfinder@latest go install -v github.com/projectdiscovery/httpx/cmd/httpx@latest # 运行 subfinder subfinder -d target.com -all -recursive -o subdomains.txt # 过滤出存活主机 cat subdomains.txt | httpx -silent -status-code -title -tech-detect -o live_hosts.txt # 快速查看返回结果 cat live_hosts.txt | sort -k2 -t'[' | head -50 ``` 查看结果。你正在寻找： - 任何带有“staging”、“dev”、“test”、“internal”、“admin”字样的内容 - 返回异常状态码（403、401、500）的子域名 - 你认为在历史上容易受到攻击的技术栈 ### 第 3 步：检查暴露的面板和默认凭据（30 分钟） ``` # 使用针对性 template set 对存活主机运行 nuclei nuclei -l live_hosts.txt -t exposures/ -t default-logins/ -o nuclei_exposures.txt # 检查常见的 admin 路径 cat live_hosts.txt | awk '{print $1}' | while read url; do for path in /admin /administrator /wp-admin /phpmyadmin /jenkins /grafana /kibana; do echo "$url$path" done done | httpx -silent -status-code -mc 200,301,302,401,403 ``` ### 第 4 步：JavaScript 文件分析（30 分钟） JavaScript 文件是金矿。开发者会将 API endpoint、内部服务 URL，有时甚至将凭据留在 JS 文件中，并被部署到生产环境。 ``` # 从一个 domain 提取所有 JS 文件 echo "https://target.com" | gau --blacklist png,jpg,gif,css | grep "\.js$" | sort -u > js_files.txt # 对每一个运行 linkfinder cat js_files.txt | while read url; do python3 linkfinder.py -i "$url" -o cli 2>/dev/null done | grep -E "(api|internal|admin|token|key|secret|password)" | sort -u ``` ### 第 5 步：测试 IDOR（30 分钟） IDOR 是现代 Web 应用程序中最容易持续复现的漏洞。其模式总是一样的：由可预测 ID 标识的用户特定资源没有被正确授权。 1. 创建两个账户（账户 A 和账户 B） 2. 作为账户 A，创建一个资源（文档、个人资料、工单、订单） —— 记录其 ID 3. 退出账户 A，切换到账户 B 4. 尝试使用其 ID 访问、修改或删除账户 A 的资源 5. 如果成功了 —— 那就是一个 IDOR ``` GET /api/v1/users/12345/profile → try /api/v1/users/12346/profile (another user) GET /api/v1/invoices/INV-001 → try INV-002 POST /api/v1/documents/delete {"id": "abc123"} → try another user's document ID ``` ### 第 6 步：编写报告 如果你发现了真正的漏洞，不要急着写报告。一份包含清晰复现步骤、证据和业务影响评估的优秀报告会得到回报，而且回报丰厚。一份草率的报告可能会被当作“仅供参考”关闭。 查看 [报告](#-reporting) 获取完整模板。 ## 项目选择指南 ### VDP 与付费项目 **漏洞披露项目（VDP）** 是无报酬的。你报告，他们修复，你得到一句感谢。这些适用于： - 在刚起步时建立你的作品集 - 在没有压力的情况下学习一种新的应用程序类型 - 政府和非营利目标，这些目标本身不是为了钱 **付费 Bug Bounty 项目** 是一旦你有了一些经验后应该投入大部分时间的地方。收益差异很大 —— 资金充足的项目的 P1 漏洞可以支付 $10,000 到 $100,000；而小型初创公司项目的 P4 漏洞可能只支付 $50。 ### 如何阅读范围文档 范围文档既是技术文档，也是法律文档。请逐字阅读。 需要注意的关键事项： **明确在范围内的是什么：** ``` *.example.com api.example.com mobile apps (iOS App Store ID: 123456, Google Play: com.example.app) ``` **明确不在范围内的是什么（关键）：** ``` blog.example.com (WordPress, third-party managed) status.example.com Any third-party services Social engineering Physical attacks ``` **测试限制：** - “禁止自动化扫描” —— 这会砍掉标准工作流的一大部分 - “禁止在生产数据上测试” —— 使用测试账户 - “速率限制测试需要事先批准” - “如果你访问了 PII，请立即报告” **大多数猎人落入的陷阱**是只阅读范围内的列表而忽略限制。我曾见过猎人因为运行自动化扫描对生产服务器造成负载而被封禁，即使目标在范围内。限制条件很重要。 ### 信噪比 有些项目实际上已经关闭了 —— 攻击面很小，团队分类缓慢，重复率超过 90%。低信噪比项目的迹象： - 范围内的表面积很小 - 响应时间历史长（检查 Hacktivity） - 最近的披露中有很多“重复”和“仅供参考” - 每份报告的平均赏金非常低 高信噪比项目的迹象： - 宽泛的通配符范围 - 快速的分类时间（平均 < 5 天） - 最近的项目上线或重大范围扩展 - 活跃的 Hacktivity，包含已解决/已奖励的报告 ### 私有与公开项目 私有项目（仅限受邀）在信噪比方面几乎总是更好的。猎人更少，攻击面更新鲜，分类更快。获得邀请主要取决于你在平台上的声誉 —— 已关闭的有效报告、低噪声、报告中良好的写作质量。 特别是在 HackerOne 上：每一份已关闭的有效报告都会增加你的声誉。受邀参加私有项目是实现稳定收入的真正秘诀。 ### 平台对比 | 平台 | 最适合 | 备注 | |----------|----------|-------| | HackerOne | 业务量、声誉建立 | 项目选择最多，最成熟 | | Bugcrowd | 托管项目、企业级目标 | 适合专注于 API/移动端的项目 | | Intigriti | 欧洲公司 | 饱和度较低，分类快 | | YesWeHack | 欧洲项目 | 不断发展的平台，高质量项目 | | Synack | 高薪审查项目 | 需要申请，背景调查 | | Immunefi | Web3/智能合约 | 高额赏金，需要不同的技能组合 | | Federacy | 较小、较新的项目 | 竞争较小 | ## Bug Bounty 经济学 让我对此诚实一点，因为大多数指南都不会这样。 ### 各技能水平的实际预期收入 **初学者（0-12 个月）：** 平均每月 $0-$500。大多数月份将是 $0。你会找到真正的漏洞，但它们通常是重复的。这个阶段主要是学习 —— 不要把它当成收入。 **中级（1-3 年）：** 每月 $500-$5,000。你有了一套方法论。你能持续发现独特的漏洞。会有一些 P2 和偶尔的 P1。收入是真实的，但不可预测。 **高级（3 年以上）：** 每月 $5,000-$30,000+。你拥有了多个高价值私有项目的受邀访问权限。你拥有自动化。你深入理解特定的技术栈。你报告迅速且写作良好。这仅占猎人的一小部分。 **前 1%：** 每年 $100,000+。这些猎人通常具有深厚的专业能力（智能合约、云原生、嵌入式/IoT）、长期的项目关系，并且除了赏金外通常还会提供咨询服务。 ### 严重程度与赏金现实 严重程度评级（P1-P4）大致对应于 CVSS 分数，但项目方有酌情决定权： | 严重程度 | CVSS 范围 | 典型赏金（成熟项目） | 通常是何种漏洞 | |----------|------------|----------------------------------|-------------------| | P1 / 严重 | 9.0–10.0 | $5,000–$100,000+ | RCE、带数据访问的 SQLi、绕过管理员身份验证 | | P2 / 高危 | 7.0–8.9 | $1,000–$10,000 | 指向内部网络的 SSRF、带敏感数据的 IDOR、敏感上下文中的存储型 XSS | | P3 / 中危 | 4.–6.9 | $100–$1,000 | Self-XSS、速率限制绕过、信息泄露 | | P4 / 低危 | 0.1–3.9 | $50–$500 | 缺失安全标头、低影响的信息泄露 | 注：这些数字适用于资金充足的成熟项目。许多项目的支出要少 10-20 倍。在投入时间之前，请检查名人堂和已披露的报告。 ### 时间投资的坦诚 Bug Bounty 的隐性成本是你花在重复漏洞上的时间。我估计，在公开项目中我发现的有效漏洞中有 30-50% 已经被报告过了。那是没有报酬的真实工作。减少这种情况的方法是：专注于私有项目，深入研究冷门功能，并将侦测置于测试之上。 一个有用心智模型：把你最初的 100 个小时当作学费。你是在学习，而不是在赚钱。 ## 仓库导航 | 章节 | 文件 | 内容 | |---------|------|---------------| | 侦测 | [methodology/recon.md](methodology/recon.md) | 资产发现、子域名枚举、JS 分析、Dorking、自动化 | | 范围与规则 | [methodology/scope-and-rules.md](methodology/scope-and-rules.md) | 阅读范围文档、安全测试、法律框架 | | Web 漏洞 | methodology/web-vulns.md | XSS、SQLi、SSRF、IDOR、业务逻辑 —— 现代测试方法 | | API 安全 | methodology/api-security.md | REST、GraphQL、gRPC —— 身份验证绕过、BOLA、注入 | | 云目标 | methodology/cloud.md | AWS、GCP、Azure —— SSRF 链、IAM 提权、S3 | | AI/LLM 目标 | methodology/ai-llm.md | 提示词注入、越狱、RAG 投毒、模型提取 | | 移动端 | methodology/mobile.md | Android/iOS —— 流量拦截、Deep Links、Keystore | | 报告 | methodology/reporting.md | 模板、严重性评级理由、证据打包 | | 工具 | methodology/tools.md | 完整的工具列表及安装命令和使用场景 | | 字典 | methodology/wordlists.md | 为不同目标类型精选的字典 | ## 侦测 简短版：花在侦测上的时间要比花在测试上的时间多。赏金丰厚的漏洞几乎从不在 `www.target.com` 上 —— 它们隐藏在 2019 年以来就没被动过的被遗忘的子域名上、意外暴露的内部工具上、开启了调试模式的 staging 环境上。 关键侦测工作流： 1. 子域名枚举 → 过滤出存活主机 2. ASN/IP 范围发现 → 寻找 CDN 外的资产 3. JS 文件分析 → 寻找 API endpoint 和密钥 4. Wayback Machine → 寻找已被移除但仍存活的 endpoint 5. GitHub/GitLab Dorking → 寻找凭据和内部工具 6. Shodan/Censys → 寻找暴露的服务 ## Web 漏洞 经典的漏洞依然存在，依然能赚钱。在 2026 年，我在各个项目中最一致发现的漏洞是： **高优先级（最高信噪比）：** - IDOR / 对象级别授权失效 - SSRF（特别是针对云元数据 endpoint） - 业务逻辑缺陷 - 身份验证绕过 - 在具有高权限上下文（管理面板、电子邮件模板）中的存储型 XSS **中优先级：** - 反射型 XSS（更难变现，大多数项目评级为 P3） - 开放重定向（通常是 P4，除非用于 OAuth 绕过） - 敏感操作上的 CSRF - 身份验证 endpoint 上的速率限制绕过 **Bug Bounty 中的低优先级（大多是参考信息）：** - 缺失安全标头（除非项目明确奖励这些） - Self-XSS - 没有实际影响证明的理论漏洞 ## API 安全 API 优先的应用程序现在是主导架构。REST、GraphQL、gRPC —— 每一种都有自己独特的漏洞模式。 **变化：** 传统的 Web 测试（使用 Burp，点击各个地方，修改请求）仍然适用，但你需要理解 API 契约才能找到业务逻辑漏洞。批量赋值、BOLA（对象级别授权失效，IDOR 的 API 叫法）和身份验证 token 范围问题是信噪比最高的目标。 **针对 GraphQL：** - 内省查询即使在“生产环境”中也会暴露完整的 schema - 批处理允许绕过速率限制 - 字段级别授权通常完全缺失 - 别名可用于在一个请求中提取多个对象 ## 云目标 云配置错误往往被少报且被超额支付。大多数猎人不知道要寻找什么，因此信噪比极高。 **云 Bug Bounty 中最高价值的利用链：** ``` SSRF on web application → Request to 169.254.169.254 (AWS IMDS) or 169.254.169.254/metadata (Azure) → Get IAM role credentials → Enumerate AWS permissions → Access S3 buckets, secrets, databases → Demonstrate impact ``` 这条利用链，如果被完整演示，在任何 AWS 托管的应用程序上通常都是 P1。 ## AI/LLM 目标 这是 2026 年 Bug Bounty 中探索最少的攻击面。各项目添加 AI 功能的速度快于保护它们的速度，而安全社区仍在摸索在这种背景下“漏洞”究竟意味着什么。 **核心漏洞类别：** - **提示词注入** —— 用户控制的输入影响了 LLM 的系统提示词行为 - **间接提示词注入** —— LLM 读取的文档/网页中的恶意内容改变了其行为 - **影响业务功能的越狱** —— 让模型绕过其预期的限制，从而造成实际伤害 - **RAG 数据投毒** —— 如果你能影响向量数据库中的内容，你就能影响 AI 的响应 - **模型 API 密钥暴露** —— 在 JS 文件或响应中找到 OpenAI/Anthropic 等的 API 密钥 - **不安全的输出处理** —— LLM 输出作为 HTML 渲染 → XSS；作为 SQL 渲染 → SQLi **有效漏洞的门槛：** 演示出业务影响。“我让 AI 说了一些粗鲁的话”不是漏洞。“我利用提示词注入从上下文窗口中提取了另一个用户的数据”是 P1。 ## 工具 不可或缺的工具（我每台机器上都装有的）： **侦测：** - `subfinder` —— 子域名枚举 - `amass` —— 被动 + 主动的 ASN 感知枚举 - `httpx` —— 带有技术检测的存活主机过滤 - `nuclei` —— 基于模板的漏洞扫描 - `gau` / `waybackurls` —— 历史 URL 收集 - `ffuf` —— 快速的 Web 模糊测试工具 - `feroxbuster` —— 递归内容发现 **漏洞利用/测试：** - `Burp Suite Pro` —— 必备工具，核心平台 - `sqlmap` —— SQL 注入（在范围内谨慎使用） - `dalfox` —— XSS 扫描器 - `jwt_tool` —— JWT 分析和攻击 - `OAuth toolkit`（Burp 插件） **云：** - `awscli` —— 直接 AWS API 访问 - `pacu` —— AWS 漏洞利用框架 - `ScoutSuite` —— 多云审计 - `cloudfox` —— AWS/Azure 攻击面发现 ## 报告 一个平庸的漏洞配上一份优秀的报告，往往比一个优秀的漏洞配上一份平庸的报告收益更高。分类团队也是人。他们必须在内部证明赏金的合理性。为他们提供证明高严重性评级合理性的弹药。 **行之有效的结构：** 1. **标题** —— 一句话，具体，包含漏洞类别和位置 2. **严重程度** —— 你的评级和 CVSS 依据 3. **总结** —— 用两到三句话说明出了什么问题以及为什么重要 4. **复现步骤** —— 编号、完整、可从头复现 5. **证据** —— 截图、HTTP 请求/响应、针对复杂漏洞的视频 6. **影响** —— 具体且与业务相关（不要写“攻击者可以...”） 7. **建议的修复方案** —— 可选但会受到赞赏，这表明你理解代码库 **扼杀赏金的错误：** 模糊的影响声明。“攻击者可以访问敏感数据”只能得到 P3。“攻击者可以通过修改 GET /api/v1/invoices/{id} 中的 user ID 参数，访问任何用户的支付历史，包括信用卡尾号、账单地址和所有时间内的交易记录”能得到 P1。 ## 贡献 发现了这里没有的技术？看到过时的内容？欢迎提交 PR。这是一份旨在不断更新的活文档 —— Bug Bounty 发展迅速，静态指南很容易过时。 查看 [CONTRIBUTING.md](CONTRIBUTING.md) 了解指南。 ## 许可证 MIT。随你怎么用 —— 用在你自己的方法论里、在你的团队中、在培训材料中。表示一下感谢即可，不作强制要求。

标签：AI安全, API安全, Chat Copilot, CISA项目, JSON输出, Web安全, 安全方法论, 实时处理, 密码管理, 蓝队分析, 防御加固