Security Bounty Hunter

安全赏金猎人

当目标是针对负责任披露或赏金提交的实际漏洞发现，而非广泛的实践审查时使用此方法。

使用场景

• 扫描代码库以发现可利用漏洞
• 准备 Huntr、HackerOne 或类似赏金平台的提交材料
• 判断"这个漏洞是否真的能获得赏金"而非"理论上是否不安全"的优先级分类

工作原理

优先关注远程可达、用户可控的攻击路径，并剔除平台通常判定为信息性或超出范围的模式。

有效模式

以下是持续具有影响力的漏洞类型：

跳过这些

除非项目另有说明，以下通常属于低信号或超出赏金范围：

• 仅限本地的 pickle.loads、torch.load 或等效且无远程路径的漏洞
• 仅限CLI工具中的 eval() 或 exec()
• 完全硬编码命令上的 shell=True
• 单独缺失安全标头
• 无利用影响的通用速率限制投诉
• 需要受害者手动粘贴代码的自XSS
• 不属于目标项目范围的CI/CD注入
• 演示、示例或仅测试代码

工作流程

1. 首先检查范围：项目规则、SECURITY.md、披露渠道和排除项。
2. 寻找真实入口点：HTTP处理器、上传功能、后台任务、Webhook、解析器和集成端点。
3. 在适用时运行静态工具，但仅将其作为分类输入。
4. 从头到尾阅读实际代码路径。
5. 证明用户控制能到达有意义的接收点。
6. 使用最小安全PoC确认可利用性和影响。
7. 在起草报告前检查重复项。

分类循环示例

semgrep --config=auto --severity=ERROR --severity=WARNING --json

然后手动过滤：

• 删除测试、演示、固定代码、供应商代码
• 删除仅限本地或不可达路径
• 仅保留具有明确网络或用户控制路由的发现

报告结构

## 描述[漏洞是什么及其重要性]
## 漏洞代码[文件路径、行号范围及代码片段]
## 概念验证[最小化可运行的请求或脚本]
## 影响[攻击者能够实现的目标]
## 受影响版本[已测试的版本、提交或部署目标]

质量关卡

提交前需确认：

• 代码路径可从真实用户或网络边界到达
• 输入确实由用户控制
• 接收点有意义且可利用
• PoC有效
• 该问题尚未被公告、CVE或公开工单覆盖
• 目标确实在赏金计划范围内