安全漏洞赏金猎人 是做什么的？
当目标是实际漏洞发现用于负责任披露或漏洞赏金提交时使用，而非进行广泛的最佳实践审查。
使用场景
- 扫描仓库以查找可利用的漏洞
- 准备 Huntr、HackerOne 或类似漏洞赏金提交
- 判定“这实际上有价值吗？”而非“这在理论上是否不安全？”的紧急程度
工作原理
倾向于远程可到达的、用户可控的攻击路径，并丢弃那些平台通常会标记为“仅供参考”或“超出范围”的模式。
在作用域内的模式
以下是持续重要的几种问题类型：
| 模式 | CWE | 典型影响 |
|---|---|---|
| 通过用户可控 URL 的 SSRF | CWE-918 | 内部网络访问、云元数据窃取 |
| 中间件或 API 防护中对认证的绕过 | CWE-287 | 未经授权的账户或数据访问 |
| 远程反序列化或上传到 RCE 路径 | CWE-502 | 代码执行 |
| 在可达端点中的 SQL 注入 | CWE-89 | 数据窃取、认证绕过、数据破坏 |
| 在请求处理程序中的命令注入 | CWE-78 | 代码执行 |
| 在文件服务路径中的路径遍历 | CWE-22 | 任意文件读取或写入 |
| 自动触发的 XSS | CWE-79 | 会话窃取、管理员权限滥用 |
跳过这些
以下通常是低信号或超出赏金范围的，除非项目另有说明：
- 仅本地的
pickle.loads、torch.load或类似功能，且无远程路径 - CLI 工具中的
eval()或exec() - 完全硬编码命令上的
shell=True - 仅凭缺失安全头
- 没有利用影响的通用速率限制投诉
- 需要受害者手动粘贴代码的自 XSS
- 不在目标项目范围内的 CI/CD 注入
- 演示、示例或仅测试代码
工作流程
- 首先检查范围：项目规则、SECURITY.md、披露渠道和排除项。
- 找到真实入口点：HTTP 处理程序、上传、后台任务、Webhook、解析器和集成端点。
- 在有用时运行静态工具，但仅将其视为分类输入。
- 从头到尾阅读实际代码路径。
- 证明用户控制能够到达一个有意义的接收点（sink）。
- 用最小的安全 PoC 确认可利用性和影响。
- 在起草报告前检查是否有重复。
示例分类循环
semgrep --config=auto --severity=ERROR --severity=WARNING --json
然后手动过滤：
- 丢弃测试、演示、测试夹具、供应商代码
- 丢弃仅本地或不可到达的路径
- 仅保留具有明确网络或用户控制途径的发现
报告结构
## 描述
[漏洞是什么及其重要性]
## 易受攻击的代码
[文件路径、行范围以及一个小片段]
## 概念验证
[最小工作请求或脚本]
## 影响
[攻击者可以实现什么]
## 受影响版本
[测试的版本、提交或部署目标]
质量关卡
在提交之前：
- 代码路径从真实用户或网络边界可达
- 输入是真正用户可控的
- 接收点（sink）有意义且可利用
- PoC 有效
- 该问题尚未被任何公告、CVE 或开放工单覆盖
- 目标实际上在赏金计划的范围内