report-writing

报告撰写

影响优先。语气自然。避免理论化表述。审查人员也是普通人。

---

最重要的规则

绝不要使用“可能有潜在风险”“可能会被用于”或“或许能让”。 要么确实能做到，要么不能。如果你没有证实，就不要声称它能做到。

BAD:  "This vulnerability could potentially allow an attacker to access user data."
GOOD: "An attacker can access any user's order history by changing the user_id
       parameter to the target user's ID. I confirmed this using two test accounts:
       [email protected] (ID 123) successfully retrieved [email protected] (ID 456)
       orders, including their shipping address and payment method last 4 digits."

---

标题公式

[Bug Class] in [Exact Endpoint/Feature] allows [attacker role] to [impact] [victim scope]

好的标题（具体，影响优先）：

IDOR in /api/v2/invoices/{id} allows authenticated user to read any customer's invoice data
Missing auth on POST /api/admin/users allows unauthenticated attacker to create admin accounts
Stored XSS in profile bio field executes in admin panel — allows privilege escalation
SSRF via image import URL parameter reaches AWS EC2 metadata service
Race condition in coupon redemption allows same code to be used unlimited times

不好的标题（模糊，对审查人员毫无帮助）：

IDOR vulnerability found
Broken access control
XSS in user input
Security issue in API
Unauthorized access to user data

---

HACKERONE 报告模板

## Summary

[One paragraph: what the bug is, where it is, what an attacker can do. Be specific.
Include: endpoint, method, parameter, data exposed, required access level.]

Example: "The `/api/users/{user_id}/orders` endpoint does not verify that the
authenticated user owns the requested user_id. An attacker can enumerate any
user's order history, including PII (email, address, phone) and purchase history,
by incrementing the user_id parameter. No privileges beyond a standard free
account are required."

## Vulnerability Details

**Vulnerability Type:** IDOR / Broken Object Level Authorization
**CVSS 3.1 Score:** 6.5 (Medium) — AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
**Affected Endpoint:** GET /api/users/{user_id}/orders

## Steps to Reproduce

**Environment:**
- Attacker account: [email protected], user_id = 123
- Victim account: [email protected], user_id = 456
- Target: https://target.com

**Steps:**

1. Log in as [email protected], obtain Bearer token

2. Send the following request:

GET /api/users/456/orders HTTP/1.1 Host: target.com Authorization: Bearer ATTACKER_TOKEN_HERE

3. Observe response:

```json
{
  "orders": [
    {"id": 789, "items": [...], "email": "[email protected]", "address": "123 Main St..."}
  ]
}

响应中包含受害者的完整订单历史和个人身份信息，尽管请求是由另一名用户发起的。

影响

经过身份验证的攻击者可以通过遍历 user_id 值来枚举所有用户订单。 这会暴露：全名、电子邮件、收货地址、购买历史和支付方式 （后 4 位）。如果有约 100K 名用户，这意味着所有注册用户都会受到 大规模个人身份信息泄露的影响。攻击者只需一个免费账户，用简单循环即可在几分钟内完成利用。

建议修复方案

添加服务器端所有权验证：

if order.user_id != current_user.id:
    raise Forbidden()

支持材料

[显示攻击者会话返回受害者订单数据的截图] [如有，提供操作演示视频]

---

## BUGCROWD REPORT TEMPLATE

```markdown
# [IDOR] User order history accessible without authorization via /api/users/{id}/orders

**VRT Category:** Broken Access Control > IDOR > P2

## Description

[Same impact-first paragraph as HackerOne summary]

## Steps to Reproduce

[Same structured steps — exact HTTP requests, exact responses]

## Proof of Concept

[Screenshot/video showing the actual impact]

## Expected vs Actual Behavior

**Expected:** 403 Forbidden when user_id does not match authenticated user
**Actual:** 200 OK with victim's full order data

## Severity Justification

P2 (High) — Direct read access to other users' PII. Affects all user accounts.
No user interaction required. Exploitable by any authenticated user.
Automated enumeration could exfil all [N] user records in minutes.

## Remediation

Add ownership verification: `if order.user_id != current_user.id: raise 403`

---

INTIGRITI 报告模板

# [Bug Class]: [Exact Impact] in [Endpoint/Feature]

## Description

[Impact-first paragraph. Start with what an attacker can do, not with how you found it.
Include: endpoint, method, parameter, data exposed, required privileges.]

## Steps to Reproduce

**Environment:**
- Attacker: [email protected] (standard account, no special role)
- Victim: [email protected]
- Tested: [date]

**Reproduction steps:**

1. [Login as attacker / visit URL / send request]

2. Send the following HTTP request:

\```http
METHOD /endpoint HTTP/1.1
Host: target.com
Authorization: Bearer ATTACKER_TOKEN
Content-Type: application/json

{"param": "victim_id_here"}
\```

3. Observe response contains victim's private data:

\```json
{"email": "[email protected]", "address": "123 Main St", ...}
\```

## Impact

[Specific, quantified impact. What data, how many users, what can attacker do.]

CVSS 3.1 Score: X.X ([Severity]) — AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

## Remediation

[1-3 sentence concrete fix. Include code if helpful.]

## Attachments

[Screenshot or Loom video showing the impact — Intigriti triagers prefer video for complex bugs]

Intigriti 专属说明：

• 标题格式：[漏洞类别]: [一句话描述影响]（不要求使用公式，但要具体）
• 严重程度由你设定：Critical/High/Medium/Low/Exceptional
• CVSS 3.1 为标准版本（较新的项目也接受 CVSS 4.0）
• PoC 视频的价值远高于单独的截图——使用 Loom 录制
• 安全港政策：Intigriti 会予以执行，因此可以放心稍微激进地进行测试

---

IMMUNEFI 报告模板

# [Bug Class] — [Protocol Name] — [Severity]

## Summary

[One paragraph with: root cause, affected function, economic impact, attack cost.
Include numbers where possible: "attacker can drain $X in Y transactions."]

## Vulnerability Details

**Contract:** `VulnerableContract.sol`
**Function:** `claimRedemption()`
**Bug Class:** Accounting State Desynchronization
**Severity:** Critical

### Root Cause

[Exact code snippet showing the vulnerable code with comments]

## Proof of Concept

```solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
// Foundry PoC — run: forge test --match-test test_exploit -vvvv

contract ExploitTest is Test {
    // ... full working exploit
}

影响

[量化描述：“攻击者可以抽走 TVL 的 X% = 按当前汇率计算的 $Y。 需要 $Z 的 gas 费用。攻击可以重复进行。”]

建议修复方案

[具体代码更改，包含更改前后对比]

---

## CVSS 3.1 QUICK SCORING

### Formula

CVSS = f(AV, AC, PR, UI, S, C, I, A)

### Metric Quick Picks

| Metric | Value | Weight | When |
|---|---|---|---|
| **Attack Vector (AV)** | Network | +0.85 | Via internet |
| | Local | +0.55 | Local access needed |
| **Attack Complexity (AC)** | Low | +0.77 | Repeatable |
| | High | +0.44 | Race/timing needed |
| **Privileges Required (PR)** | None | +0.85 | No login |
| | Low | +0.62 | Regular user account |
| | High | +0.27 | Admin account |
| **User Interaction (UI)** | None | +0.85 | No victim action |
| | Required | +0.62 | Victim must click |
| **Scope (S)** | Changed | higher | Affects browser/OS/other |
| | Unchanged | lower | Stays in app |
| **Confidentiality (C)** | High | +0.56 | All data exposed |
| | Low | +0.22 | Limited data |
| **Integrity (I)** | High | +0.56 | Can modify any data |
| **Availability (A)** | High | +0.56 | Crashes service |

### Typical Scores by Bug Class

| Bug | Typical CVSS | Severity |
|---|---|---|
| IDOR (read PII) | 6.5 | Medium |
| IDOR (write/delete) | 7.5 | High |
| Auth bypass → admin | 9.8 | Critical |
| Stored XSS (any user) | 5.4–8.8 | Med–High |
| SQLi (data exfil) | 8.6 | High |
| SSRF (cloud metadata) | 9.1 | Critical |
| Race condition (double spend) | 7.5 | High |
| GraphQL auth bypass | 8.7 | High |
| JWT none algorithm | 9.1 | Critical |

---

## SEVERITY DECISION GUIDE

### Critical (P1)
- Full account takeover of any user without interaction
- Remote code execution
- SQLi with ability to dump/modify entire DB
- Auth bypass to admin panel
- SSRF to cloud metadata → IAM credentials exfil

### High (P2)
- Mass PII exposure (email, phone, SSN, payment data)
- Privilege escalation from user to admin
- SSRF reaching internal services (data returned)
- Stored XSS executing for all users of sensitive feature
- Payment bypass / financial loss without limit

### Medium (P3)
- IDOR on specific user's non-critical data
- XSS on low-sensitivity page requiring victim interaction
- CSRF on important but non-critical action
- Rate limit bypass on OTP (with effort demonstrated)

### Low (P4)
- Information disclosure (non-sensitive, no PII)
- Clickjacking on sensitive action WITH working PoC
- CORS on limited data

---

## SEVERITY SELF-ASSESSMENT

Each YES raises severity:

1. 泄露其他用户的个人身份信息／健康／财务数据？ → 严重程度 +1
2. 可接管账户或提升权限？ → 严重程度 +2
3. 受害者无需进行任何用户交互？ → 严重程度 +1
4. 影响所有用户（而非仅在特定条件下影响）？ → 严重程度 +1
5. 无需访问内部网络即可远程利用？ → High+ 的基准条件

---

## DOWNGRADE COUNTERS

| Program Says | Counter With |
|---|---|
| "Requires authentication" | "Attacker needs only a free account — no special role or permission" |
| "Limited impact" | "Affects [N] users / exposes [PII type] / $[amount] at risk" |
| "Already known" | "Show me the report number — I searched hacktivity and found none" |
| "By design" | "Show me the documentation stating this is intended behavior" |
| "Low CVSS" | "CVSS doesn't capture business impact — attacker can extract [X] in [Y] minutes" |
| "Not exploitable" | "Here is the exact response showing victim's data returned to attacker session" |

---

## THE 60-SECOND PRE-SUBMIT CHECKLIST

[ ] 标题符合公式：[类别] 位于 [端点]，允许 [攻击者] 实现 [影响] [ ] 首句用通俗语言准确说明具体影响 [ ] 复现步骤包含准确的 HTTP 请求（可直接复制粘贴） [ ] 提供显示漏洞的响应（截图或 JSON 正文） [ ] 使用两个测试账户，而不是让单个账户测试自身 [ ] 已计算并注明 CVSS 分数 [ ] 建议修复方案为 1-2 句话（不要长篇说教） [ ] 端点路径或参数名称没有拼写错误 [ ] 报告少于 600 个单词——审查人员会略读冗长的报告 [ ] 声称的严重程度与描述的影响相符——不要夸大 [ ] 从未使用“可能有潜在风险”或“或许能让” [ ] 审查人员可从全新状态复现 PoC

---

## CVSS 4.0 QUICK REFERENCE (newer programs)

CVSS 4.0 replaced CVSS 3.1 in November 2023. Some newer programs require it.

### Key Differences from CVSS 3.1

| Metric | CVSS 3.1 | CVSS 4.0 |
|---|---|---|
| Attack Vector | Network/Adjacent/Local/Physical | Same |
| Attack Complexity | Low/High | Low/High |
| **NEW**: Attack Requirements | (didn't exist) | None/Present (replaces some PR/UI) |
| Privileges Required | None/Low/High | Same |
| User Interaction | None/Required | None/Passive/Active |
| Scope | Unchanged/Changed | REMOVED |
| **NEW**: Sub-Impact metrics | (didn't exist) | Vulnerable/Subsequent system impact |

### CVSS 4.0 Score Examples

| Finding | CVSS 4.0 Score | Vector |
|---|---|---|
| Unauthenticated RCE | 10.0 | CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H |
| IDOR read PII, auth required | 6.9 | CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N |
| Stored XSS, admin views it | 8.2 | CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N |
| SSRF → cloud metadata | 8.7 | CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:N |

### Quick CVSS 4.0 Calculator

使用：https://www.first.org/cvss/calculator/4.0 关键字段： VC/VI/VA = 易受攻击系统的机密性／完整性／可用性 SC/SI/SA = 后续系统（下游影响） AT = None（无特殊条件）| Present（需要竞争条件／特定配置） UI = None | Passive（受害者访问 URL）| Active（受害者执行明确操作）

**Practical rule**: If program uses CVSS 4.0 and you don't know the vector, use the calculator and include the full string starting with `CVSS:4.0/AV:...`. Programs cannot dispute a valid vector string.

---

## HUMAN TONE GUIDELINES

**Write to a person, not a system:**
- Triagers are tired. Get to the impact in sentence 1.
- Use "I" not "the researcher" — you found it, own it
- Short paragraphs, bullet points for steps
- Hyperlink relevant docs if needed

**Escalation language (when payout is being downgraded):**

“此漏洞不需要任何特殊权限——只需一个免费账户。” “暴露的数据包含 [PII 类型]，受 GDPR 要求约束。” “攻击者可以用简单循环自动化此操作——几分钟内即可获取全部 [N] 条记录。” “无需访问任何内部系统的网络，即可从外部利用此漏洞。” “其影响相当于 [功能／数据类型] 的全面数据泄露。”

**Avoid:**
- Jargon the triager might not know
- 5-paragraph explanations of what IDOR is (they know)
- Theoretical chains ("could be combined with X to...")
- Passive voice ("it was observed that...")
- Qualifying language ("seems to," "appears to")

---

## STEPS TO REPRODUCE FORMAT (triager-optimized)

```markdown
**Setup:**
- Account A (attacker): [email protected], ID=111
- Account B (victim): [email protected], ID=222
- Both created via normal registration — no special access

**Steps:**

1. Log in as Account A
2. Send this request (replace `111` with victim ID `222`):

\```
GET /api/v2/resource/222 HTTP/1.1
Host: target.com
Authorization: Bearer ACCOUNT_A_TOKEN
\```

3. Response contains Account B's private data:

\```json
{"id": 222, "email": "[email protected]", "name": "Victim User", "address": "..."}
\```

**Expected:** 403 Forbidden
**Actual:** 200 OK with victim's private data

---

相关技能与链路

• triage-validation — 用于判断是否应该撰写报告。工作流基元：在 triage-validation 的 7 问门槛通过前，绝不要打开此技能；未通过门槛的发现应予以淘汰，而不是写成报告。
• bugcrowd-reporting — 目标属于 Bugcrowd 项目时使用。工作流基元：此技能的正文模板是基础；bugcrowd-reporting 会在此基础上叠加 VRT 选择、严重性请求段落以及对 OOS 条款的反驳。
• evidence-hygiene — 报告中需要附上 PoC 截图 / HAR 时使用。工作流基元：「Supporting Materials」/「Proof of Concept」部分中引用的每件材料，在附加前都要交由 evidence-hygiene 进行 Cookie 和 PII 脱敏。
• redteam-report-template — 项目属于外部红队测试（不是漏洞赏金）时使用。工作流基元：通过 bb-methodology PART 0 确认项目模式；如果是红队测试，则用 redteam-report-template 替换此技能（受众和结构不同：Subject / Observations / Description / Impact / Recommendation / PoC）。

---

操作人员须知（Claude-BugHunter）

基于项目实践，对供应的基础内容进行补充。内容来自真实的授权项目，以及本仓库 31+ 个技能领域的实时测试所做的第 2 阶段验证。上游方法论介绍 WHAT（是什么）；这一层介绍 WHEN-IT-ACTUALLY-WORKS（实际奏效的情况）和 FAILURE-MODES（失败模式）。

实践中的标题公式

<asset> | <bug class> | <impact> — 由三个部分组成，不添加废话。分诊人员通常只花约 3 秒阅读标题，并据此安排队列顺序。

• 不佳：「Interesting finding on /api/users」
• 不佳：「IDOR vulnerability in API」
• 优秀：「Authenticated IDOR on /api/users/{uid} -> admin email + role disclosure」
• 优秀：「Unauthenticated SSRF on /preview?url= -> AWS metadata 169.254.169.254 reachable」

不佳的标题会最后才被打开。优秀的标题会最先被打开。同一个发现，队列位置不同，分诊时间不同，奖金到账速度也不同。

分诊人员实际会看什么

他们阅读新报告的顺序如下：

1. 标题（3 秒）
2. 影响 / 摘要的首段（15 秒）
3. curl 命令或 HTTP 请求块（30 秒）
4. 复现步骤（仅当前三项令人信服时才会看）
5. 其他所有内容（仅在后续审核时才会看）

务必精心优化报告开头。叙述性内容放在中间。被第 3 步说服的分诊人员会直接认可其余内容；未被第 3 步说服的分诊人员不会看第 5 步。

CVSS 3.1、Bugcrowd VRT 与 H1 默认严重性

这三种体系约有 30% 的情况下评定结果不一致。最常见的差异是：CVSS 评分为 7.x（高危）的发现，在 Bugcrowd 中对应 P4（低危），或在 H1 中默认为中危。当平台默认评级低于 CVSS 时：

1. 将严重性请求段落作为正文的第一部分提交。 Bugcrowd 会考虑这一点。（标准模板请参阅 bugcrowd-reporting。）
2. 用 CVSS 向量字符串和业务影响作为请求依据，而不是诉诸主观感受。「CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N = 7.5 High，因为机密性：跨租户数据泄露适用高危评级。」
3. 引用与该发现相匹配的平台自有 VRT 条目。 不要反驳平台；应在其体系内提出请求。

某次经授权的漏洞赏金项目中，默认评级为 P4 的发现通过严重性请求段落升级到了 P3。升级并非自动发生——你必须在正文第一部分提出请求，并提供有依据的理由。

证据轮换

提交正文中的所有内容都会被平台永久记录。请据此行事：

• 使用专为此次测试创建的一次性测试账号。
• 每次提交后轮换 Cookie / 令牌（不要重复使用粘贴在报告中的 Cookie）。
• 切勿在报告正文中粘贴生产环境 Cookie、真实用户邮箱或真实个人身份信息（PII）——在 PoC 步骤中对其进行脱敏。
• 管理面板截图：模糊处理用户列表；如果 URL 栏中包含令牌，也要将其模糊处理。

请交叉链接 evidence-hygiene，查看完整的采集与脱敏流程。

按平台划分的模板——平台间存在差异时

平台	语气	必需结构	严重性判定机制
HackerOne	叙述式	概述 -> 步骤 -> 影响 -> 建议的修复方案	由分诊人员设定，可提出异议
Bugcrowd	结构化	严重性请求 -> VRT 类别 -> 标题 -> 正文 -> 修复措施	VRT 默认值 + 手动覆盖说明段落
Intigriti	介于两者之间	概述 -> PoC -> 影响 -> 建议	研究人员提出，分诊人员确认
Immunefi	PoC 优先	可运行的 PoC 代码 -> 演示过程 -> 影响 -> 严重性	Foundry/Hardhat 代码是主要交付物

选错模板风格会导致报告失效。叙述内容过多的 Bugcrowd 报告缺少分诊人员需要的 VRT 映射；结构化的 H1 报告则会显得过于简短，引发后续提问并延迟付款。

撰写报告时最容易犯的错误

声称某种攻击“理论上”可行，或“可能与[更大影响]串联”，却没有实际演示。分诊验证 Q6（超出技术上可能范围的影响）会在验证环节否决此类报告；撰写报告时也必须遵循同一要求。

有两种有效做法：

1. 端到端展示具体影响。 在测试账号上记录完整攻击链。粘贴完整的请求 / 响应序列。完成。
2. 降低严重性声明，使其与实际演示的内容相符。 “/api/users/{uid} 上的 IDOR，可读取邮箱和角色”是真实且可报告的问题；“可串联 IDOR，可能导致管理员账号失陷”则不成立，除非你实际演示了账号失陷。

二选一。绝不要折中使用“可能有机会”或“或许允许”之类的说法——这些措辞会向分诊人员表明报告仅停留在理论层面，而理论性报告会被判为 N/A。

• bb-methodology — 第 5 阶段的报告撰写步骤开始时使用。工作流基元：第 5 阶段调用 /report，加载此技能以获取平台专属模板（H1 / Bugcrowd / Intigriti / Immunefi）。