# Bugbounty Workflow

> 授权范围内(补天/SRC 等赏金平台)漏洞挖掘全流程工作流:侦察→挖掘→验证→报告。当用户要求"挖洞""挖漏洞""测目标""渗透测试""打点""提交SRC/补天"时使用。

- Skill: `jensen-yao/bugbounty-workflow` (Agent Skill, multi-file: 11 files)
- Install (CLI): `npx skillmds@latest add jensen-yao/bugbounty-workflow`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jensen-yao/bugbounty-workflow/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: Jensen-Yao (https://skillmd.com/u/jensen-yao)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/jensen-yao/bugbounty-workflow

---


# Bug Bounty 全流程工作流

面向补天/SRC 等**授权范围内**的漏洞挖掘任务。按 5 个阶段推进:每阶段产出工件、与用户确认后再进入下一阶段。**严禁跳过阶段 0。**

## 铁律(全程有效,违反即终止任务)

1. **只测授权资产**:目标必须来自补天项目页、厂商授权等书面范围,范围外资产一律不测。
2. **不做破坏性测试**:禁止 DoS、删改数据、锁账号、高频扫描。
3. **数据最小化**:证明漏洞即可,禁止拖库/批量下载;SQL 注入用 `LIMIT 1` 或单次时间盲注确认。
4. **证据脱敏**:截图打码敏感信息;获取的敏感数据不落盘、不传播。
5. **报告真实**:不夸大等级;高危先报,未修复前不公开细节。

## 工作目录约定

任务开始时在用户工作目录下创建:

```
bugbounty/
├── 00-scope/scope.md       # 授权与范围确认
├── 01-recon/               # 资产清单、存活、指纹、功能入口
├── 02-scan/                # 扫描结果、候选漏洞清单
├── 03-verify/evidence/     # 验证记录、证据(截图/请求响应)
├── 04-report/              # 最终报告(一洞一份)
└── submit/                 # 每个漏洞一个 zip(附件,≤50M)
```

## 平台知识(补天/SRC,详见 reference/butian-submission.md)

1. **专属 vs 公益 SRC**:报告"提交平台"栏必须与项目实际类型一致;先向用户确认类型再写报告。专属=厂商私有项目,公益=公众项目。
2. **定级口径**(常见):低危 1kb 无积分(druid 未授权、短信/邮箱轰炸、源码泄露、信息泄露、挂黑页等);中危 2-3kb(SQL 注入、越权、XSS、弱口令等;SQLi 提权至 shell 算高危);高危 4kb(命令执行、代码执行、文件上传、可 getshell)。
3. **漏洞类别**:Web/IoT/工控/操作系统及通用软件;漏洞类型:事件型/通用型。
4. **平台分类字段**(报告"漏洞类型(平台分类)"从中选):XSS、配置错误、弱口令、入侵事件、疑似被黑、文件上传、信息泄露、存在后门、逻辑漏洞、代码执行、命令执行、SQL注入、解析漏洞。
5. **详情要求**:完整利用过程+URL+截图+代码+POC,不达标可能审核不过;IoT 需二进制位置/目标配置/研究环境;用到的组件给下载链接或附件上传;视频压缩后附件或链接。
6. **附件限制**:仅 zip/rar、≤50M、仅压缩组件/固件/视频;截图在详情中直接上传。

## 阶段 0:授权与范围确认(强制)

1. 向用户索要:平台项目页链接(补天公益 SRC/专属 SRC 页面)、目标资产、授权说明。
2. 用 WebFetch 打开项目页,记录:资产范围(域名/IP/APP/小程序)、允许的测试类型、禁止事项、提交要求、评级标准。
3. 写入 `00-scope/scope.md`。**不在范围内的资产后续一律不测**;范围模糊时先问用户,不自行扩大。
4. 用户无法提供任何授权依据 → 拒绝执行主动测试,只提供学习建议(本地靶场:Vulhub/Pikachu/DVWA)。

## 阶段 1:侦察

1. 检查工具可用性,缺失则提示安装方式(见文末),有缺失也可用被动方式替代。
2. 执行 `bash scripts/recon.sh <domain>`(子域收集、crt.sh、历史 URL、存活探测、指纹、Nuclei 扫描;缺失工具自动跳过)。
3. 补充被动收集:
   - 网络空间测绘(用户自有 FOFA/Quake 账号):关联资产、框架指纹、敏感文件。
   - WebSearch:备案信息、GitHub/代码托管泄露(dork:`域名 password` / `apikey` / `secret`)、公开漏洞报告。
   - 手动浏览主站:功能清单(登录/注册/找回密码/支付/上传等入口),截图记录。
4. 指纹识别:重点记录中间件、框架、CMS 及版本,查对应已知漏洞(版本核对到 CVE)。
5. 边缘资产策略(单厂商深度挖掘,详见 `checklists/edge-asset-checklist.md`):
   - 资产分级:dev/pre/test 环境、后台/OA、API 域、历史废弃资产 → 防护最弱,优先测;核心资产最后测。
   - 子域字典补 `dev test pre staging uat oa vpn mail api m wx` 等前缀;JS 中引用到的兄弟域名纳入清单。
   - 小程序/APP:抓包拿接口域名,反编译找密钥与隐藏接口。

**产出**:`01-recon/assets.md`(资产清单:子域+IP+端口+指纹+状态码)与功能入口清单。
**确认点**:与用户过一遍资产清单,圈定优先测试目标(默认按边缘资产优先),再进入挖掘。

## 阶段 2:漏洞挖掘

**自动化(结果必须人工复核)**:

- Nuclei 命中逐条复核,多数是误报。
- 目录扫描(dirsearch/ffuf,限速 `-t 20`):重点找备份文件、未授权接口、编辑器、`.git/`/`.svn/` 泄露。
- JS 接口收集:gau/waybackurls 历史 URL;下载 JS 提取 API 路径与硬编码密钥。

**人工测试(核心,逐项对照 `checklists/web-vuln-checklist.md`)**:

- 认证:弱口令/默认口令、验证码绕过、短信轰炸、找回密码逻辑
- 越权:水平(IDOR)、垂直
- 业务逻辑:支付/优惠券/流程跳过/并发
- 注入:SQLi、命令注入、模板注入
- XSS、SSRF、文件上传、CORS/未授权、信息泄露

**专项策略(按场景对照)**:

- 边缘资产/dev-pre 环境/小程序/密码重置 → `checklists/edge-asset-checklist.md`
- 通用 CMS 批量刷洞(备份泄露/后台弱口令/未授权,可提通用型)→ `checklists/cms-batch-checklist.md`

每个可疑点先记入 `02-scan/candidates.md`(资产、位置、可疑行为、初步想法),攒够一批再进验证阶段,避免边挖边验打乱节奏。

## 阶段 3:验证(最小影响原则)

对每个候选逐个验证,方法按类型(详见清单文件"验证与证据"栏):

- SQLi:手工 payload 或 sqlmap 仅确认注入点(`--batch --random-agent --level 2`,不跑 `--dump-all`);盲注单次延时确认。
- 越权/IDOR:仅换 ID 确认能访问他人资源,截图即止;不批量遍历、不下载数据。
- SSRF:用 dnslog.cn / interactsh 收带外请求确认;不深入探测内网。
- XSS:弹窗或带外确认即可。
- 文件上传:只传无害探针;证明解析后立即删除,不驻留 webshell。

每个确认的漏洞:

1. 保存证据:请求/响应原文、截图(打码敏感信息)→ `03-verify/evidence/`。
2. 写复现步骤(从"未登录/低权测试账号"开始)→ `03-verify/verified.md`。
3. 定级:参考平台评级标准 + 实际影响,不虚报。

误报:标注原因后移出候选。
**确认点**:与用户核对每个已确认漏洞的等级和证据完整性,再写报告。

## 阶段 4:报告

按 `templates/report-template.md` 为每个漏洞单独生成 `04-report/` 下的报告:

- 标题格式:`<系统/站点>存在<漏洞类型>`
- 必含:基本信息、描述、复现步骤(带请求包)、危害、修复建议、测试合规声明。
- 基本信息表必须含:漏洞类型(事件型/通用型)、漏洞分类(Web/IoT/工控/操作系统及通用软件)、漏洞类型(平台分类字段)、危害程度(低危1kb/中危2-3kb/高危4kb)、提交平台(专属SRC/公益SRC,与项目实际一致)。
- 提交前检查:描述与实际影响一致、复现步骤审核员可复现、截图已打码、一洞一报。
- 提交前重读平台当前规则(规则会更新);提交后跟进修复进度,修复前不公开细节。

### 阶段 4 收尾:证据打包(提交附件)

1. 为每个漏洞生成一个压缩包 → `submit/BUG-<编号>-<英文简述>.zip`。
2. 包内全部用 **ASCII 文件名**:截图按 `01_xxx.png`/`02_xxx.png` 排序重命名,附 curl 原始响应 `03_xxx.txt`、POC 脚本 `poc_xxx.py`(标准库、可直接运行)、报告 `report_xx.md`。
3. 附件限制:仅 zip/rar、≤50M(仅组件/固件/视频);**截图在"漏洞细节"里直接上传**,压缩包放组件/POC/报告。
4. 打包后校验:列出包内条目确认文件齐全;并给用户输出"每个报告需提交的附件清单"。
5. 平台明示低危无积分(1kb 档)时,提示用户自行决定是否提交。

## 环境与工具

缺失工具安装建议(WSL2 或 Git Bash;Go 系 `go install xxx@latest`):

- 侦察:`subfinder`、`httpx`、`nuclei`、`gau`、`nmap`
- 挖掘:`dirsearch`、`ffuf`、`sqlmap`、Burp Suite
- 带外交互:`dnslog.cn`(网页,国内常用)或 `interactsh-client`

Windows 注意:脚本经 Git Bash 运行;复杂环境建议 WSL2 跑工具链。

