ghost-validate

安全发现验证

确定安全发现是真阳性还是假阳性。给出判定并提供支持证据。

输入

用户提供一个文件路径或粘贴的文本。如果两者都未提供，请向用户索取。

提取：漏洞类别、具体声明、受影响的端点、代码位置，以及任何现有的验证证据。

验证工作流

步骤 1：了解安全发现

识别：

• 漏洞类别（BFLA、BOLA、XSS、SQLi、SSRF 等）
• 所提出的具体声明（缺少哪项授权检查、哪些输入未经过净化等）
• 受影响的端点和 HTTP 方法
• 代码位置

步骤 2：分析源代码

1. 阅读指定行号所在的漏洞文件及所有支持文件
2. 从路由注册开始，经由中间件追踪到处理程序，梳理请求流
3. 验证具体声明——代码是否确实缺少所述检查？
4. 查找扫描器可能遗漏的间接保护（中间件、辅助函数、ORM 约束）
5. 确认在所述条件下，漏洞代码路径可被触达

步骤 3：实时验证（可用时）

如果可以访问应用程序的实时实例，并且可通过实时交互确认漏洞，请使用 proxy 技能确认漏洞是否可利用：

1. 启动作用域限定为目标域名的 reaper 代理
2. 以合法用户身份进行身份验证（或由用户进行身份验证），并捕获发往易受攻击端点的有效请求
3. 重放或修改请求，尝试利用安全发现中描述的漏洞
4. 将响应与预期行为进行比较：
   • 未授权操作是否成功？（真阳性）
   • 服务器是否以 401/403/404 拒绝请求？（假阳性）
5. 使用 reaper get <id> 捕获请求/响应对作为证据

步骤 4：作出判定

将安全发现归类为以下其中一种：

• 真阳性：漏洞确实存在且可被利用。代码缺少所述保护，并且端点可被触达。
• 真阳性（已确认）：同上，且实时测试已证明可成功利用。
• 假阳性：漏洞不存在。说明具体原因（发现间接保护、代码路径不可触达等）。
• 无法确定：缺少额外信息，无法作出判定。说明需要哪些信息。

步骤 5：报告

按以下格式输出摘要：

1. 判定：真阳性、假阳性或无法确定
2. 置信度：高、中或低
3. 证据摘要：代码审查和／或实时测试的关键发现
4. 代码分析：支持该判定的具体行和逻辑
5. 实时测试结果（如已执行）：展示行为的请求／响应对
6. 建议：真阳性则修复，假阳性则关闭，无法确定则收集更多信息

示例：

## Validation Result
- **Determination**: True Positive
- **Confidence**: High
- **Evidence**: Handler at routes/transfers.go:142 queries transfers by ID without checking ownership. No middleware or ORM-level constraint enforces user scoping.
- **Recommendation**: Add ownership check — include user_id in the WHERE clause.

步骤 6：保存结果

如果安全发现是通过文件路径提供的，请询问用户是否希望将验证详情追加到原始发现文件中。如果用户同意，请在文件中追加一个 ## Validation 部分，其中包含判定、置信度、证据摘要和建议。

漏洞类别参考

请参阅此技能目录中的 VULNERABILITY_PATTERNS.md，了解验证授权缺陷（BFLA/BOLA/IDOR）、注入（SQLi/XSS）和身份验证缺陷时需要查找的模式。