security-bounty-hunter

安全赏金猎手

当目标是出于负责任披露或赏金提交的目的进行实际漏洞发现时使用此技能，而非广泛的最佳实践审查。

何时使用

• 扫描仓库以发现可利用的漏洞
• 准备 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
• 单独缺少安全头
• 没有利用影响的通用速率限制投诉
• 需要受害者手动粘贴代码的 Self-XSS
• 不在目标项目范围内的 CI/CD 注入
• 演示、示例或仅测试代码

工作流

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

示例分诊循环

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

然后手动过滤：

• 丢弃测试、演示、fixture、vendored 代码
• 丢弃仅本地的或不可达的路径
• 仅保留有明确网络或用户可控路径的发现

报告结构

## 漏洞描述
[漏洞是什么以及为什么重要]

## 脆弱代码
[文件路径、行范围和小段代码片段]

## 概念验证
[最小可用的请求或脚本]

## 影响
[攻击者可以达到什么目的]

## 受影响版本
[测试的版本、提交或部署目标]

质量门

在提交之前：

• 代码路径可从真实用户或网络边界到达
• 输入确实是用户可控的
• 接收点有意义且可利用
• PoC 可以正常工作
• 问题尚未被安全公告、CVE 或开放工单覆盖
• 目标确实在赏金项目范围内