evidence-hygiene

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

EVIDENCE HYGIENE — PoC Capture & Redaction Discipline

证据卫生规范 — PoC 采集与脱敏纪律

Use this skill BEFORE capturing any screenshot, exporting any HAR, or attaching any evidence to a bug-bounty submission. It catches the most common evidence-hygiene mistakes that cause cookies to leak, PII to be shared without consent, or screenshots to be unsuitable for triage.

The core principle: Bug-bounty evidence is meant to convince a triager. Anything beyond that — live cookies, real-user PII, internal trace IDs that aren't useful — should not be in the evidence.

在截取任何截图、导出任何 HAR 或将任何证据附加到漏洞赏金提交之前，先使用此 skill。它能发现最常见的证据卫生失误，这些失误会导致 Cookie 泄露、未经同意共享 PII，或使截图不适合分类审核。

核心原则：漏洞赏金证据旨在说服审核人员。除此之外的任何内容——有效的 Cookie、真实用户 PII、无用的内部 Trace ID——都不应出现在证据中。

1. Two Categories of Sensitive Data

1. 两类敏感数据

Every PoC artifact (screenshot, HAR, raw HTTP request, terminal transcript) potentially contains data that needs different treatment.

Category	Examples	Treatment
Your-account secrets	Session cookies, OAuth tokens, refresh tokens, API keys	Always redact. Even in private bug-bounty platform attachments. Your account, your session — protect it.
Other users' PII	Real names, emails, phone numbers, addresses, profile photos, account IDs	Redact unless explicitly demonstrating cross-account impact. Even then, mask faces and minimize the data you display.
Triager-useful metadata	Trace IDs ( `x-datadog-trace-id` ), request IDs, server timestamps, your test account UID/email, GraphQL operation names, response shapes	Leave visible — these help the triager correlate to logs and reproduce.
Test-account passwords (limited use)	Throwaway passwords on a test account (e.g., `Testing@5678` )	Acceptable in screenshots if you rotate immediately after submission so the value shown is dead. Don't leave real-use passwords in evidence.

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

类别	示例	处理方式
你的账户机密	Session Cookie、OAuth Token、Refresh Token、API Key	始终脱敏。即使在私有漏洞赏金平台附件中也应如此。你的账户、你的 Session——务必保护。
其他用户的 PII	真实姓名、电子邮件、电话号码、地址、头像、账户 ID	除非明确演示跨账户影响，否则应脱敏。即使如此，也要遮住面部并尽量减少展示的数据。
对审核人员有用的元数据	Trace ID（ `x-datadog-trace-id` ）、Request ID、服务器时间戳、你的测试账户 UID/Email、GraphQL Operation Name、响应结构	保持可见——这些有助于审核人员关联日志并进行复现。
测试账户密码（限制使用）	测试账户的一次性密码（如 `Testing@5678` ）	如果在提交后立即轮换，使截图中显示的值随即失效，则可接受用于截图。不要在证据中保留实际使用的密码。

2. Cookie Redaction Protocol

2. Cookie 脱敏协议

2.1 What must be masked

2.1 必须遮蔽的内容

The session cookie value is the highest-value secret in any PoC. Mask:

The session cookie (
```
authn
```
,
```
session
```
,
```
sid
```
,
```
__Secure-id
```
, etc. — name varies per target)
```
csrf-token
```
if it's bound to your session
```
Authorization
```
headers (Bearer tokens, JWT)
```
Cookie
```
request header values for any session-bearing cookie
```
Set-Cookie
```
response header values for any session-bearing cookie

Session Cookie 值是任何 PoC 中价值最高的机密。需要遮蔽：

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

2.2 What's safe to leave visible

2.2 可安全保持可见的内容

Cloudflare cookies (
```
__cf_bm
```
,
```
_cfuvid
```
) — these are bot-management, not session-bearing
Analytics cookies (
```
ajs_anonymous_id
```
,
```
_ga
```
)
Trace correlation IDs (
```
x-datadog-trace-id
```
,
```
x-request-id
```
)
Server / framework headers (
```
Server: cloudflare
```
,
```
X-Frame-Options
```
)
Your test account email/UID (per Bugcrowdninja alias section in
```
bugcrowd-reporting
```
)

Cloudflare Cookie（
```
__cf_bm
```
、
```
_cfuvid
```
）——用于 Bot 管理，不是 Session 型
Analytics Cookie（
```
ajs_anonymous_id
```
、
```
_ga
```
）
Trace 关联 ID（
```
x-datadog-trace-id
```
、
```
x-request-id
```
）
Server / Framework 标头（
```
Server: cloudflare
```
、
```
X-Frame-Options
```
）
你的测试账户 Email/UID（按照
```
bugcrowd-reporting
```
中
```
bugcrowdninja
```
alias 章节的规定）

2.3 Redaction methods (ranked by practicality)

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

Method A — Don't capture the cookies in the first place (preferred when possible)

For DevTools Console PoCs: use
```
credentials: 'include'
```
so the browser sends cookies automatically. Console output won't echo the cookie. Screenshot the Console output, never the Network tab Headers panel.
For Burp Repeater PoCs: drag the bottom request/response panel divider DOWN to hide the request body before screenshotting. Capture only the Results table for Intruder runs.

Method B — Black-bar in image editor (when capture inevitably includes cookies)

macOS: Open screenshot in Preview → Tools → Annotate → Rectangle → set fill color to black → drag rectangle over the cookie value → save
Windows: Use Snip & Sketch's annotation tools or any image editor (Paint.NET, etc.)
Burp itself: in Burp's Proxy → Match and Replace, you can pre-emptively redact cookie values to placeholder strings before screenshotting

Method C — Find/replace in raw text (for HAR files, terminal transcripts)

See §4 for the jq commands

方法 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 文件、终端记录）

参见第 4 节中的 jq 命令

2.4 Pre-screenshot checklist

2.4 截图前检查清单

Before clicking 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)

After capturing:

[ ] 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

点击 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 Black-Bar Protocol

3. PII 黑条脱敏协议

When a PoC necessarily exposes another user's data (e.g., demonstrating IDOR by showing the victim's email in an attacker-session response), redact the actual PII even in private attachments.

当 PoC 不可避免地暴露其他用户的数据时（例如，通过在攻击者 Session 的响应中显示受害者的 Email 来演示 IDOR），即使在私有附件中也应遮蔽实际 PII。

3.1 What to mask (other-user data)

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

First name, last name (full or partial)
Email address (mask the local part; can leave domain if non-identifying)
Phone number (mask the last 7 digits, optionally leave country code)
Physical address (mask everything below city)
Date of birth (mask the year, optionally the month)
Government IDs (SSN, passport — mask everything)
Profile photos / face images (black-bar the face entirely)
Account IDs that the user could correlate to public profiles

名和姓（完整或部分）
Email 地址（遮蔽本地部分；如果域名无法识别身份，则可以保留）
电话号码（遮蔽最后 7 位数字，可以选择保留国家代码）
实际地址（遮蔽城市以下的所有内容）
出生日期（遮蔽年份，可以选择保留月份）
政府身份证件（SSN、护照——全部遮蔽）
头像/面部图像（用黑条完全遮住面部）
用户可能与公开资料关联起来的账户 ID

3.2 What to leave visible (proves the bug, not the user)

3.2 保持可见的内容（证明漏洞，而不是证明用户）

The fact that the field was returned (the JSON key name)
The shape / type of the field (
```
"first_name": "<REDACTED>"
```
)
Your own (attacker session's) UID / email — this proves cross-account
The endpoint URL and request method
The trace ID

该字段确实被返回这一事实（JSON Key 名称）
字段的结构/类型（
```
"first_name": "<REDACTED>"
```
）
你自己的（攻击者 Session 的）UID/Email——这可以证明跨账户访问
Endpoint URL 和请求方法
Trace ID

3.3 Worked example — IDOR PoC body

3.3 实例——IDOR PoC 响应正文

Bad (leaks victim's full PII):

json

{"data":{"contact":{"first_name":"Nadene","last_name":"Afton","email":"nadene.afton@example.com","phone":"+1-555-867-5309"}}}

Good (proves the bug, masks the PII):

json

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

In screenshot form, black-bar each value with a rectangle annotation labeled "REAL PII REDACTED" if there's space.

错误（泄露受害者的完整 PII）：

json

{"data":{"contact":{"first_name":"Nadene","last_name":"Afton","email":"nadene.afton@example.com","phone":"+1-555-867-5309"}}}

正确（证明漏洞，同时遮蔽 PII）：

json

{"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 In the report body

3.4 在报告正文中

Reference the redaction explicitly:

markdown

undefined

明确说明脱敏情况：

markdown

undefined

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.


This signals the triager that you're disciplined and gives them a clear path to the unredacted version if they need it for verification.

---


这可以向审核人员表明你具备规范的证据处理意识，同时为他们提供一条获取未脱敏版本以供验证的明确路径。

---

4. HAR File Sanitization

4. HAR 文件清理

HAR (HTTP Archive) files are JSON dumps of network traffic with full request/response bodies and headers. They include cookies, auth tokens, and any PII that was in transit.

HAR（HTTP Archive）文件是网络流量的 JSON 转储，包含完整的请求/响应正文和标头。它们包含 Cookie、Auth Token 以及传输过程中出现的所有 PII。

4.1 Generate the HAR

4.1 生成 HAR

Chrome DevTools → Network tab → right-click anywhere in the request list → "Save all as HAR with content"

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

4.2 Sanitize before attaching

4.2 附加前进行清理

Use

jq

to strip sensitive headers. Save this as a shell function or one-liner you can re-use:

bash

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"
}

Usage:

bash

sanitize_har /path/to/exported.har

使用

jq

移除敏感标头。将以下内容保存为可重复使用的 Shell Function 或单行命令：

bash

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"
}

使用方式：

bash

sanitize_har /path/to/exported.har

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

undefined

undefined

4.3 Verify before attaching

4.3 附加前进行验证

bash

undefined

bash

undefined

Check that no Cookie or Authorization values are leaking

grep -i 'authn|"cookie"|authorization' /path/to/exported.sanitized.har | head -20


If you see your real cookie value in the output, the sanitization missed something — fix the jq filter for that specific field name.

grep -i 'authn|"cookie"|authorization' /path/to/exported.sanitized.har | head -20


如果输出中出现你的真实 Cookie 值，说明脱敏遗漏了某些内容——针对该特定字段名修正 jq 过滤器。

4.4 Remove other-user PII (if applicable)

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

If the HAR captured cross-account data (e.g., during an IDOR demo), additionally strip the response body fields that contain victim PII. Add to the jq filter:

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

Customize the gsub patterns to your specific captured data.

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

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

根据捕获到的具体数据调整 gsub 模式。

5. Burp Suite Screenshot Hygiene

5. Burp Suite 截图卫生规范

5.1 Repeater (single request demo)

5.1 Repeater（单请求演示）

In the Repeater request panel, the Cookie header is on its own line — drag the panel divider DOWN to hide everything below the request line / target line
Or: temporarily delete the Cookie header text from the Repeater pane (it doesn't affect the original captured request) before screenshotting, then restore
Capture only the response panel (right side) showing the JSON / HTML response that demonstrates the bug

在 Repeater 请求面板中，Cookie 标头单独占一行——向下拖动面板分隔线，隐藏请求行/目标行下方的所有内容
或者：截图前临时从 Repeater 窗格中删除 Cookie 标头文本（这不会影响最初捕获的请求），然后恢复
仅捕获显示漏洞的 JSON/HTML 响应的响应面板（右侧）

5.2 Intruder Results table (rate-limit / brute-force demos)

5.2 Intruder Results 表格（限流/暴力破解演示）

The Results window is the strongest evidence for rate-limit findings. To capture cleanly:

After the attack finishes, drag the horizontal divider between the Results table and the Request/Response panels DOWN, until only the Results table is visible

Screenshot only the columns:

Request#

Payload

Status code

Response received

Length

Don't include the Request / Response sub-panels — they contain the cookie

Results 窗口是限流问题最有力的证据。要干净地采集：

攻击完成后，将 Results 表格与 Request/Response 面板之间的水平分隔线向下拖动，直到仅剩 Results 表格可见

只截取以下列：

Request#

、

Payload

、

Status code

、

Response received

、

Length

不要包含 Request/Response 子面板——其中包含 Cookie

5.3 Proxy HTTP history (capture demo)

5.3 Proxy HTTP History（捕获演示）

Almost never the right screenshot — it shows entire request/response pairs with cookies. Use Repeater for demos instead.

几乎从来都不是正确的截图对象——它会显示带有 Cookie 的完整请求/响应配对。演示时改用 Repeater。

5.4 Scanner findings (if applicable)

5.4 Scanner Findings（如适用）

The Scanner tab's Issues panel is generally safe to screenshot — it shows finding summaries without the underlying request bodies. Click into a specific finding before screenshotting only if you've redacted its evidence first.

Scanner 标签页的 Issues 面板通常可以安全截图——它只显示发现摘要，不含底层请求正文。只有在已对证据脱敏后，才可点击进入具体问题再截图。

6. Chrome DevTools Console PoC Patterns

6. Chrome DevTools Console PoC 模式

6.1 The clean-PoC pattern

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)))

Why this is clean:

```
credentials: 'include'
```
means the browser sends cookies. Your code never references them. They never appear in screenshots.
```
console.log("LABEL:", ...)
```
produces a labeled output line you can search for in the screenshot
```
JSON.stringify(j)
```
formats the response on a single line — easier to crop tightly

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 Multi-step PoCs (clear console between calls)

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

For a 4-step PoC (verify before / change / verify after / revert), clear the console between calls so each screenshot only shows ONE call and ONE response:

Mac:
```
Cmd+K
```
Windows / Linux:
```
Ctrl+L
```

Take the screenshot immediately after the response prints — don't wait for unrelated framework warnings to appear.

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

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

响应打印后立即截图——不要等待无关的 Framework Warning 出现。

6.3 Long responses (truncate for screenshot)

6.3 长响应（截图前截断）

If the response body is too long for a clean screenshot, log a summary instead:

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)
  })

如果响应正文过长，无法得到清晰截图，则改为记录摘要：

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 Allow-pasting reminder

6.4 允许粘贴提醒

Chrome blocks paste into DevTools Console as anti-self-XSS protection. Type

allow pasting

(literal phrase) once at the start of each session. Do this BEFORE you take any "running PoC" screenshot — otherwise the warning text appears in the screenshot.

Chrome 出于自我 XSS 防护，会阻止向 DevTools Console 粘贴内容。每个会话开始时输入一次

allow pasting

（字面短语）。在拍摄任何“运行中的 PoC”截图之前完成此操作——否则警告文字会出现在截图中。

7. Screenshot Capture Order Discipline

7. 截图采集顺序纪律

7.1 The 5-step PoC pattern (for state-change findings)

7.1 5 步 PoC 模式（用于状态变更类问题）

For findings like "password change without step-up," the canonical 5-screenshot pattern is:

Pre-state verification —
```
verify_password("current") → true
```
. Proves you knew the starting state.
The bug itself —
```
update_password(...)
```
succeeds without step-up. THE most important screenshot.
Post-state verification (negative) —
```
verify_password("old") → false
```
. Proves the change took effect.
Post-state verification (positive) —
```
verify_password("new") → true
```
. Proves the new credential is active.
Out-of-band side effects — inbox screenshot showing whether a notification email arrived. Proves whether passive defense exists.

对于“无需 Step-Up 即可修改密码”之类的问题，标准的 5 张截图模式是：

前置状态验证——
```
verify_password("current") → true
```
。证明你了解起始状态。
漏洞本身——
```
update_password(...)
```
在没有 Step-Up 的情况下成功。这是最重要的截图。
后置状态验证（否定结果）——
```
verify_password("old") → false
```
。证明更改已生效。
后置状态验证（肯定结果）——
```
verify_password("new") → true
```
。证明新凭据已启用。
带外副作用——收件箱截图，显示是否收到通知邮件。证明是否存在被动防御。

7.2 Filename conventions

7.2 文件命名约定

Numbered, descriptive, hyphen-separated:

{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

In the report body, reference each by filename:

markdown

- **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.

使用编号清晰、以连字符分隔的名称：

{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

在报告正文中，按文件名引用每个截图：

markdown

- **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 Capture timing

7.3 采集时机

Take all screenshots in one sitting, not across multiple sessions. Mid-session inconsistencies (different browser sizes, different cookie values) are confusing for the triager.
Don't reload pages between screenshots if avoidable. Reloads regenerate cookies and may invalidate prior captures.

一次会话中完成所有截图，不要跨多个会话采集。跨会话的不一致（不同浏览器尺寸、不同 Cookie 值）会让审核人员困惑。
尽量不要在截图之间重新加载页面。重新加载会重新生成 Cookie，并可能使之前的捕获失效。

8. Post-Submission Hygiene

8. 提交后卫生规范

After clicking Submit on the bug-bounty platform:

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

8.1 Rotate the test account credentials

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)

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 Save the unredacted artifacts privately

8.2 私下保存未脱敏产物

Keep your unredacted HARs / screenshots in a local folder accessible only to you. The triager may ask for the unredacted version during verification. Never share unredacted artifacts via email — use the platform's private attachment system on the existing submission thread.

将未脱敏的 HAR/截图保存在仅你自己可访问的本地文件夹中。审核人员可能会在验证期间要求提供未脱敏版本。绝不要通过电子邮件分享未脱敏产物——应使用现有提交线程中平台的私有附件系统。

8.3 Don't post about the finding publicly

8.3 不要公开发布该发现

Most platforms' confidentiality applies to BOTH unresolved and resolved issues. Don't tweet, blog, or discuss the finding in any forum until the program explicitly says you can.

大多数平台的保密要求同时适用于尚未解决和已经解决的问题。在平台明确允许之前，不要通过 Tweet、博客或任何论坛讨论该发现。

8.4 Audit your local artifacts

8.4 审计本地产物

Quarterly, sweep your

~/security-research/

and

~/Downloads/

for stale HARs / screenshots from old engagements. Either move them to a properly-encrypted archive or delete them. Bug-bounty engagement artifacts are sensitive — they accumulate fast and become a liability.

每季度检查

~/security-research/

和

~/Downloads/

，查找旧项目中遗留的 HAR/截图。将它们移入妥善加密的归档，或直接删除。漏洞赏金项目产物非常敏感，会快速累积并成为潜在风险。

9. Pairing with Other Skills

9. 与其他 Skill 配套使用

For this question / task	Use this skill
"Should I report this finding at all?"	`triage-validation`
"What's the report body template?"	`report-writing`
"What VRT / severity / OOS rebuttal for Bugcrowd?"	`bugcrowd-reporting`
"How do I redact / sanitize this evidence?"	This skill ( `evidence-hygiene` )
"How do I demonstrate the bug actually fires?"	`security-arsenal`
"Where are the recon probes for this asset class?"	`offensive-osint`

针对此问题/任务	使用此 skill
“我应该报告这个发现吗？”	`triage-validation`
“报告正文模板是什么？”	`report-writing`
“针对 Bugcrowd 的 VRT/严重性/OOS 反驳是什么？”	`bugcrowd-reporting`
“如何对证据进行脱敏或清理？”	此 skill（ `evidence-hygiene` ）
“如何证明漏洞确实被触发？”	`security-arsenal`
“这类资产的 Recon Probe 在哪里？”	`offensive-osint`

Notes on usage

使用说明

This skill is meant to be loaded together with

report-writing

and (for Bugcrowd)

bugcrowd-reporting

when preparing a submission. It does NOT cover:

What to capture (that's
```
triage-validation
```
and
```
report-writing
```
's job — they tell you what evidence is required for the report to be accepted)
How to demonstrate exploitation (that's
```
security-arsenal
```
's job — payloads to send)
Where to find the assets (that's
```
offensive-osint
```
's job — recon)

This skill covers ONLY the redaction / sanitization / hygiene layer that sits between "I have evidence" and "I'm attaching it to the platform."

此 skill 旨在与

report-writing

以及（针对 Bugcrowd 的）

bugcrowd-reporting

一起加载，用于准备提交。它不涵盖：

应捕获什么——这是
```
triage-validation
```
和
```
report-writing
```
的职责；它们会告诉你报告被接受所需的证据
如何演示漏洞利用——这是
```
security-arsenal
```
的职责，包括需要发送的 Payload
在哪里查找资产——这是
```
offensive-osint
```
的职责，即 Recon

此 skill 仅涵盖位于“我已有证据”和“即将将其附加到平台”之间的脱敏/清理/卫生层。