evidence-hygiene

证据卫生——PoC 截取与脱敏规范

在截取任何屏幕截图、导出任何 HAR 或将任何证据附加到漏洞赏金提交内容之前，请先使用此技能。它能避免最常见的证据卫生问题，这些问题可能导致 Cookie 泄露、未经同意分享个人身份信息（PII），或屏幕截图不适合用于分诊。

核心原则：漏洞赏金证据旨在说服分诊人员。超出此目的的内容——有效 Cookie、真实用户的 PII、无实用价值的内部跟踪 ID——都不应出现在证据中。

---

1. 两类敏感数据

每件 PoC 证据（屏幕截图、HAR、原始 HTTP 请求、终端记录）都可能包含需要区别处理的数据。

类别	示例	处理方式
你自己的账户机密	会话 Cookie、OAuth 令牌、刷新令牌、API 密钥	始终脱敏。即使是在私人漏洞赏金平台的附件中也不例外。账户和会话都属于你——请妥善保护。
其他用户的 PII	真实姓名、电子邮件、电话号码、地址、个人资料照片、账户 ID	除非明确展示跨账户影响，否则应脱敏。即便如此，也要遮挡面部并尽量减少展示的数据。
对分诊人员有用的元数据	跟踪 ID（x-datadog-trace-id）、请求 ID、服务器时间戳、你的测试账户 UID/电子邮件、GraphQL 操作名称、响应结构	保持可见——这些信息有助于分诊人员关联日志并复现问题。
测试账户密码（有限使用）	测试账户的一次性密码（例如 Testing@5678）	如果在提交后立即更换，截图中可以显示，因为截图所示的密码届时已失效。不要在证据中留下实际使用的密码。

---

2. Cookie 脱敏规范

2.1 必须遮盖的内容

会话 Cookie 值是任何 PoC 中价值最高的机密。请遮盖：

• 会话 Cookie（authn、session、sid、__Secure-id 等——名称因目标而异）
• 与你的会话绑定的 csrf-token
• Authorization 请求头（Bearer 令牌、JWT）
• 任何包含会话 Cookie 的 Cookie 请求头值
• 任何包含会话 Cookie 的 Set-Cookie 响应头值

2.2 可以安全保留可见的内容

• Cloudflare Cookie（__cf_bm、_cfuvid）——这些用于机器人管理，不承载会话信息
• 分析 Cookie（ajs_anonymous_id、_ga）
• 跟踪关联 ID（x-datadog-trace-id、x-request-id）
• 服务器／框架请求头（Server: cloudflare、X-Frame-Options）
• 你的测试账户电子邮件／UID（参见 bugcrowd-reporting 中的 Bugcrowdninja 别名章节）

2.3 脱敏方法（按实用性排序）

方法 A——从一开始就不要截取 Cookie（条件允许时优先采用）

• 对于 DevTools Console PoC：使用 credentials: 'include'，让浏览器自动发送 Cookie。Console 输出不会回显 Cookie。截取 Console 输出，绝不要截取 Network 面板的 Headers 面板。
• 对于 Burp Repeater PoC：向下拖动请求／响应面板之间的底部分隔线，在截图前隐藏请求正文。运行 Intruder 时仅截取 Results 表格。

方法 B——在图像编辑器中用黑条遮盖（截图不可避免地包含 Cookie 时使用）

• macOS：在 Preview 中打开屏幕截图 → Tools → Annotate → Rectangle → 将填充色设为黑色 → 在 Cookie 值上拖动矩形 → 保存
• Windows：使用 Snip & Sketch 的注释工具或任何图像编辑器（如 Paint.NET）
• Burp 本身：在 Burp 的 Proxy → Match and Replace 中，可以在截图前预先将 Cookie 值替换为占位字符串

方法 C——在原始文本中查找并替换（用于 HAR 文件、终端记录）

• jq 命令请参见 §4

2.4 截图前检查清单

点击 Capture 前：

[ ] Network tab Headers panel is collapsed or out of frame
[ ] Burp's Request panel is hidden behind the divider drag
[ ] No "Copy as cURL" output is visible on screen
[ ] DevTools Application → Storage → Cookies tab is closed
[ ] Browser URL bar doesn't show a session token in query string (rare but possible)

截图后：

[ ] Open the screenshot at full resolution before saving
[ ] Search for the session cookie name substring in any visible text — if present, redact
[ ] Search for the literal first 6 chars of your cookie value — if present, redact
[ ] Compare to the previous PoC screenshot in the same engagement — same redaction discipline

---

3. PII 黑条遮盖规范

当 PoC 必须暴露其他用户的数据时（例如，通过在攻击者会话的响应中显示受害者的电子邮件来展示 IDOR），即使是在私人附件中，也要将实际 PII 脱敏。

3.1 需要遮盖的内容（其他用户的数据）

• 名字、姓氏（全部或部分）
• 电子邮件地址（遮盖本地部分；如果域名不会泄露身份，可以保留）
• 电话号码（遮盖最后 7 位，可选择保留国家代码）
• 住址（遮盖城市以下的所有信息）
• 出生日期（遮盖年份，可选择遮盖月份）
• 政府签发的证件号码（SSN、护照号码——全部遮盖）
• 个人资料照片／人脸图像（用黑条完全遮挡人脸）
• 用户可能会将其与公开资料关联起来的账户 ID

3.2 应保留可见的内容（用于证明漏洞，而非识别用户）

• 字段确实被返回这一事实（JSON 键名）
• 字段的结构／类型（"first_name": "<REDACTED>"）
• 你自己的（攻击者会话的）UID／电子邮件——用于证明跨账户访问
• 端点 URL 和请求方法
• 跟踪 ID

3.3 示例——IDOR PoC 请求体

不妥（泄露受害者的完整 PII）：

{"data":{"contact":{"first_name":"Nadene","last_name":"Afton","email":"[email protected]","phone":"+1-555-867-5309"}}}

妥当（证明漏洞，同时遮盖 PII）：

{"data":{"contact":{"first_name":"<REDACTED — real first name>","last_name":"<REDACTED — real last name>","email":"<REDACTED>@example.com","phone":"<REDACTED>"}}}

如果使用截图，请为每个值添加矩形标注并用黑条遮挡；空间允许时，标注文字为“REAL PII REDACTED”。

3.4 报告正文中

明确说明已进行遮盖：

## Proof of Concept

The screenshot below demonstrates the IDOR. The attacker session (uid 12345678) successfully retrieves the victim's profile data (uid 99887766). **Real PII fields in the response are masked with black rectangles to limit unauthorized exposure of victim data, per responsible-disclosure hygiene.** The unredacted response is available privately on request.

这能让分诊人员知道你处理得很谨慎；如果他们需要未遮盖版本进行验证，也能清楚了解如何获取。

---

4. HAR 文件清理

HAR（HTTP Archive）文件是网络流量的 JSON 转储，包含完整的请求／响应正文和标头。其中包括 Cookie、身份验证令牌，以及传输过程中的任何 PII。

4.1 生成 HAR

Chrome DevTools → Network 标签页 → 在请求列表任意位置单击右键 → “Save all as HAR with content”

4.2 附加前进行清理

使用 jq 移除敏感标头。将其保存为 Shell 函数或可重复使用的单行命令：

sanitize_har() {
  local input="$1"
  local output="${1%.har}.sanitized.har"

  jq '
    .log.entries |= map(
      (.request.headers |= map(
        if .name | ascii_downcase | IN("cookie", "authorization", "x-csrf-token") then .value = "<REDACTED>" else . end
      )) |
      (.response.headers |= map(
        if .name | ascii_downcase | IN("set-cookie") then .value = "<REDACTED>" else . end
      )) |
      (.request.cookies |= map(.value = "<REDACTED>")) |
      (.response.cookies |= map(.value = "<REDACTED>"))
    )
  ' "$input" > "$output"

  echo "Sanitized: $output"
}

用法：

sanitize_har /path/to/exported.har
# Output: /path/to/exported.sanitized.har

4.3 附加前进行验证

# Check that no Cookie or Authorization values are leaking
grep -i 'authn\|"cookie"\|authorization' /path/to/exported.sanitized.har | head -20

如果输出中出现了真实 Cookie 值，说明清理时遗漏了内容——请针对该字段名修正 jq 过滤器。

4.4 移除其他用户的 PII（如适用）

如果 HAR 捕获了跨账户数据（例如在 IDOR 演示期间），还应移除响应正文中包含受害者 PII 的字段。将以下内容添加到 jq 过滤器：

(.response.content.text |= (
  if . then 
    (fromjson? // .) | tostring | gsub("real.first.name.example"; "<REDACTED>")
  else . end
))

请根据实际捕获的数据自定义 gsub 匹配模式。

---

5. Burp Suite 截图规范

5.1 Repeater（单个请求演示）

1. 在 Repeater 请求面板中，Cookie 标头单独占一行——将面板分隔线向下拖动，隐藏请求行／目标行以下的所有内容
2. 或者：截图前，临时从 Repeater 面板中删除 Cookie 标头文本（不会影响原始捕获的请求），然后再恢复
3. 仅截取响应面板（右侧），显示用于证明漏洞的 JSON／HTML 响应

5.2 Intruder 结果表（速率限制／暴力破解演示）

结果窗口是速率限制问题最有力的证据。要清晰地截取：

1. 攻击完成后，将结果表与请求／响应面板之间的水平分隔线向下拖动，直到只显示结果表
2. 截图仅包含以下列：Request#、Payload、Status code、Response received、Length
3. 不要包含请求／响应子面板——其中包含 Cookie

5.3 Proxy HTTP 历史记录（捕获演示）

几乎从来都不适合用作截图——它会显示完整的请求／响应对，其中包含 Cookie。演示时请改用 Repeater。

5.4 Scanner 发现项（如适用）

Scanner 标签页的 Issues 面板通常可以安全截图——其中显示发现项摘要，不包含底层请求正文。只有在先遮盖特定发现项的证据后，才点击进入该发现项并截图。

---

6. Chrome DevTools 控制台 PoC 模式

6.1 整洁的 PoC 模式

fetch('/api/endpoint', {
  method: 'POST',
  headers: {'content-type': 'application/json'},
  credentials: 'include',  // sends cookies automatically — they won't appear in your code
  body: JSON.stringify({ /* your payload */ })
}).then(r => r.json()).then(j => console.log("LABEL:", JSON.stringify(j)))

这样做整洁的原因：

• credentials: 'include' 表示浏览器会发送 Cookie。你的代码不会引用它们，也不会在截图中显示它们。
• console.log("LABEL:", ...) 会生成带标签的输出行，方便你在截图中查找。
• JSON.stringify(j) 会将响应格式化为单行，便于精准裁剪。

6.2 多步骤 PoC（每次调用之间清空控制台）

对于 4 步 PoC（验证变更前 / 执行变更 / 验证变更后 / 恢复），请在每次调用之间清空控制台，以确保每张截图只显示一次调用和一个响应：

• Mac：Cmd+K
• Windows / Linux：Ctrl+L

响应打印出来后立即截图——不要等待无关的框架警告出现。

6.3 响应较长时（截断以便截图）

如果响应正文太长，无法清晰截图，请改为记录摘要：

fetch('/api/endpoint', { /* ... */ })
  .then(r => r.json())
  .then(j => {
    console.log("RESPONSE SHAPE:", Object.keys(j.data || {}));
    console.log("CRITICAL FIELD:", j.data?.victim_id, j.data?.email);
    // (Don't dump the full j — your screenshot becomes unreadable)
  })

6.4 允许粘贴提醒

Chrome 会出于防止自我 XSS 的保护机制，阻止向 DevTools Console 粘贴内容。每次会话开始时，输入一次 allow pasting（原样输入这句话）。务必在拍摄任何“PoC 正在运行”的截图之前完成此操作，否则警告文字会出现在截图中。

---

7. 截图顺序规范

7.1 5 步 PoC 模式（适用于状态变更类发现）

对于“无需二次验证即可更改密码”这类发现，标准的 5 张截图模式如下：

1. 变更前状态验证——verify_password("current") → true。证明你知道初始状态。
2. 漏洞本身——update_password(...) 无需二次验证即可成功。这是最重要的截图。
3. 变更后状态验证（否定）——verify_password("old") → false。证明变更已生效。
4. 变更后状态验证（肯定）——verify_password("new") → true。证明新凭据已启用。
5. 带外副作用——收件箱截图，显示是否收到通知邮件。证明是否存在被动防御。

7.2 文件名约定

使用带编号、描述性且以连字符分隔的文件名：

{finding-#}-step{step-#}-{description}.png

Examples:
04-step1-verify-true-before.png
04-step2-update-password-no-stepup.png
04-step3-verify-false-after.png
04-step4-verify-true-new-pw.png
04-step5-inbox-notification-check.png

在报告正文中，通过文件名引用每张截图：

- **Screenshot 1 (`04-step1-verify-true-before.png`)** — verify_password returns true with the current password.
- **Screenshot 2 (`04-step2-update-password-no-stepup.png`)** — update_password returns User with no StepUpRequiredError. THIS IS THE BUG.
- **Screenshot 3 (`04-step3-verify-false-after.png`)** — verify_password with old password returns false.
- **Screenshot 4 (`04-step4-verify-true-new-pw.png`)** — verify_password with new password returns true.
- **Screenshot 5 (`04-step5-inbox-notification-check.png`)** — inbox showing whether out-of-band notification was sent.

7.3 截图时机

• 在同一场会话中拍完所有截图，不要分多次会话拍摄。会话中途出现的不一致（浏览器尺寸不同、Cookie 值不同）会让审核人员感到困惑。
• 如无必要，不要在截图之间重新加载页面。重新加载会重新生成 Cookie，也可能导致先前拍摄的内容失效。

---

8. 提交后的注意事项

在漏洞赏金平台上点击 Submit 后：

8.1 轮换测试账户凭据

1. Log out of the target
2. Log back in (this rotates the session cookie — any cookie shown in your screenshots is now dead)
3. Change the password to a fresh value not used elsewhere (any password shown in your screenshots is now dead)

8.2 私下保存未打码的材料

将未打码的 HAR 文件和截图保存在只有你能访问的本地文件夹中。审核人员可能会在验证期间要求你提供未打码版本。切勿通过电子邮件分享未打码的材料——请使用现有提交帖中的平台私密附件系统。

8.3 不要公开谈论此发现

大多数平台的保密要求适用于尚未解决和已解决的问题。除非项目明确表示可以公开，否则不要在 Twitter 发帖、写博客或在任何论坛讨论此发现。

8.4 审查本地材料

每季度检查 ~/security-research/ 和 ~/Downloads/，清理旧项目中遗留的 HAR 文件和截图。将它们移至妥善加密的归档，或直接删除。漏洞赏金项目的材料十分敏感——它们很快就会堆积起来，成为风险。

---

9. 与其他技能配合使用

针对这个问题 / 任务	使用此技能
“我到底该不该报告这个发现？”	triage-validation
“报告正文的模板是什么？”	report-writing
“针对 Bugcrowd，VRT / 严重性 / OOS 反驳该怎么写？”	bugcrowd-reporting
“如何打码 / 清理这些证据？”	此技能（evidence-hygiene）
“如何证明漏洞确实会触发？”	security-arsenal
“这类资产的侦察探测在哪里？”	offensive-osint

---

使用说明

准备提交内容时，本技能应与 report-writing 一起加载；如果是 Bugcrowd，还应同时加载 bugcrowd-reporting。本技能不涵盖：

• 要捕获什么（这是 triage-validation 和 report-writing 的工作——它们会告诉你报告需要哪些证据才能被接受）
• 如何展示漏洞利用过程（这是 security-arsenal 的工作——提供要发送的有效载荷）
• 在哪里查找目标资产（这是 offensive-osint 的工作——侦察）

本技能只涵盖从“我有证据”到“我将证据附加到平台”之间的脱敏、清理和规范处理环节。

---

相关技能与流程链

• report-writing — 证据完成脱敏并可用于报告正文时使用。工作流基元：脱敏通过截图前检查清单后，交由 report-writing 生成适用于特定平台的报告模板（H1 / Bugcrowd / Intigriti / Immunefi）。
• bugcrowd-reporting — 脱敏后的证据专门用于 Bugcrowd 时使用。工作流基元：脱敏后的截图和已清理的 HAR 文件将作为附件，在 bugcrowd-reporting 的 VRT 映射提交正文中引用。
• triage-validation — 确定是否需要证据以及需要哪些证据时使用。工作流基元：triage-validation 会说明“密码更改时无需额外验证的漏洞需要一份包含 5 张截图的 PoC”；本技能会说明“如何干净地捕获并脱敏这 5 张截图”。
• security-arsenal — 记录生成证据的有效载荷时使用。工作流基元：有效载荷（来自 security-arsenal）原样放入报告；其输出／响应（由本技能处理）在截图前对 Cookie 和个人身份信息进行脱敏。
• bb-methodology — 第 5 阶段（验证与报告）需要捕获证据时使用。工作流基元：第 5 阶段的证据捕获步骤会先经过本技能处理，再起草报告。