Back to Details

ghost-validate

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Security Finding Validation

安全发现验证

Determine whether a security finding is a true positive or false positive. Produce a determination with supporting evidence.
判断安全发现是真阳性还是假阳性，并给出带有支持证据的判定结果。

Input

输入

The user provides a finding as a file path or pasted text. If neither is provided, ask for one.
Extract: vulnerability class, specific claim, affected endpoint, code location, and any existing validation evidence.
用户以文件路径或粘贴文本的形式提供安全发现。若两者均未提供，则请用户提供其中一种。
提取以下信息：漏洞类别、具体声明、受影响的端点、代码位置，以及任何已有的验证证据。

Validation Workflow

验证流程

Step 1: Understand the Finding

步骤1：理解安全发现

Identify:
  • The vulnerability class (BFLA, BOLA, XSS, SQLi, SSRF, etc.)
  • The specific claim being made (what authorization check is missing, what input is unsanitized, etc.)
  • The affected endpoint and HTTP method
  • The code location
识别以下内容：
  • 漏洞类别（BFLA、BOLA、XSS、SQLi、SSRF等）
  • 所提出的具体声明（例如缺少何种授权检查、哪些输入未被净化等）
  • 受影响的端点及HTTP方法
  • 代码位置

Step 2: Analyze the Source Code

步骤2：分析源代码

  1. Read the vulnerable file at the specified line number and all supporting files
  2. Trace the request flow from route registration through middleware to the handler
  3. Verify the specific claim — does the code actually lack the described check?
  4. Look for indirect protections (middleware, helpers, ORM constraints) the scanner may have missed
  5. Confirm the vulnerable code path is reachable under the described conditions
  1. 读取指定行号对应的易受攻击文件及所有支持文件
  2. 追踪从路由注册、中间件到处理程序的请求流程
  3. 验证具体声明——代码是否确实缺少所述的检查？
  4. 寻找扫描工具可能遗漏的间接保护措施（中间件、辅助工具、ORM约束等）
  5. 确认在所述条件下，易受攻击的代码路径是否可达

Step 3: Live Validation (When Available)

步骤3：实时验证（若可行）

If a live instance of the application is accessible and the vulnerability can be confirmed through live interaction, use the 
proxy
skill to confirm exploitability:
  1. Start reaper proxy scoped to the target domain
  2. Authenticate (or have the user authenticate) as a legitimate user and capture a valid request to the vulnerable endpoint
  3. Replay or modify the request to attempt the exploit described in the finding
  4. Compare the response to expected behavior:
    • Does the unauthorized action succeed? (true positive)
    • Does the server reject it with 401/403/404? (false positive)
  5. Capture the request/response pair as evidence using 
    reaper get <id>
若可访问应用的实时实例，且可通过实时交互确认漏洞，则使用
proxy
Skill验证可利用性：
  1. 启动针对目标域的reaper代理
  2. 以合法用户身份认证（或让用户完成认证），并捕获针对易受攻击端点的有效请求
  3. 重放或修改请求，尝试执行发现中描述的攻击
  4. 将响应与预期行为对比：
    • 未授权操作是否成功？（真阳性）
    • 服务器是否以401/403/404拒绝请求？（假阳性）
  5. 使用
    reaper get <id>
    捕获请求/响应对作为证据

Step 4: Make Determination

步骤4：做出判定

Classify the finding as one of:
  • True Positive: The vulnerability exists and is exploitable. The code lacks the described protection and the endpoint is reachable.
  • True Positive (Confirmed): Same as above, plus live testing demonstrated successful exploitation.
  • False Positive: The vulnerability does not exist. Provide the specific reason (indirect protection found, code path unreachable, etc.).
  • Inconclusive: Cannot determine without additional information. Specify what is needed.
将发现分类为以下类型之一：
  • 真阳性：漏洞存在且可被利用。代码缺少所述保护措施，且端点可达。
  • 已确认的真阳性：与上述情况相同，且通过实时测试证明可成功利用。
  • 假阳性：漏洞不存在。给出具体原因（如发现间接保护措施、代码路径不可达等）。
  • 无法确定：若无额外信息则无法判定。说明所需的信息。

Step 5: Report

步骤5：生成报告

Output a summary in the following format:
  1. Determination: True Positive, False Positive, or Inconclusive
  2. Confidence: High, Medium, or Low
  3. Evidence Summary: Key findings from code review and/or live testing
  4. Code Analysis: Specific lines and logic that support the determination
  5. Live Test Results (if performed): Request/response pairs demonstrating the behavior
  6. Recommendation: Fix if true positive, close if false positive, gather more info if inconclusive
Example:
undefined
按以下格式输出摘要：
  1. 判定结果：真阳性、假阳性或无法确定
  2. 置信度：高、中或低
  3. 证据摘要：代码审查和/或实时测试的关键发现
  4. 代码分析：支持判定结果的具体代码行及逻辑
  5. 实时测试结果（若执行）：展示行为的请求/响应对
  6. 建议：若为真阳性则修复，若为假阳性则关闭，若无法确定则收集更多信息
示例：
undefined

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.
undefined
  • 判定结果：真阳性
  • 置信度：高
  • 证据：routes/transfers.go:142处的处理程序按ID查询转账记录时未检查所有权。无中间件或ORM级约束强制用户范围限制。
  • 建议：添加所有权检查——在WHERE子句中包含user_id。
undefined

Step 6: Persist Results

步骤6：保存结果

If the finding was provided as a file path, ask the user if they would like to append the validation details to the original finding file. If they agree, append a 
## Validation
section to the file containing the determination, confidence, evidence summary, and recommendation.
若发现是以文件路径形式提供的，询问用户是否希望将验证详情追加到原始发现文件中。若用户同意，则在文件中添加
## 验证
部分，包含判定结果、置信度、证据摘要和建议。

Vulnerability Class Reference

漏洞类别参考

See 
VULNERABILITY_PATTERNS.md
in this skill directory for patterns to look for when validating authorization flaws (BFLA/BOLA/IDOR), injection (SQLi/XSS), and authentication flaws.
请查看该Skill目录中的
VULNERABILITY_PATTERNS.md
，其中包含验证授权缺陷（BFLA/BOLA/IDOR）、注入（SQLi/XSS）和认证缺陷时需关注的模式。