安全赏金猎人 是做什么的？
当目标是进行实际漏洞发现以用于负责任披露或赏金提交，而非进行广泛的“最佳实践”审查时，使用此技能。
何时使用
- 扫描仓库以寻找可利用漏洞
- 准备提交给 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、解析器和集成端点。
- 在有用的情况下运行静态工具，但只将其视为初步筛选输入。
- 从头到尾阅读实际代码路径。
- 证明用户控制能达到一个有意义的接收器。
- 使用尽可能小且安全的概念验证（PoC）确认可利用性和影响。
- 在起草报告前检查是否有重复。
示例甄别循环
semgrep --config=auto --severity=ERROR --severity=WARNING --json
然后手动过滤：
- 排除测试、演示、固定代码、供应商代码
- 排除仅本地或不可达路径
- 只保留具有清晰网络或用户控制路由的发现
报告结构
## 描述
[漏洞是什么以及为什么重要]
## 易受攻击代码
[文件路径、行范围及代码片段]
## 概念验证
[最小可运行请求或脚本]
## 影响
[攻击者能够实现什么]
## 受影响版本
[测试过的版本、提交或部署目标]
质量检查
在提交前：
- 代码路径是从真实用户或网络边界可达的
- 输入是真正的用户控制
- 接收器有意义且可利用
- 概念验证有效
- 问题尚未被任何公告、CVE 或公开工单覆盖
- 目标确实在赏金计划范围内