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
• 单独的安全头缺失
• 没有利用影响的通用速率限制投诉
• 需要受害者手动粘贴代码的自 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 或公开工单覆盖
• 目标确实在赏金计划范围内