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

---

验证

1. 人类语气检查——确认已标记 AI 特征词：

   grep -q "comprehensive\|leverage\|seamless\|ensure\|delve" SKILL.md && echo "FAIL: AI-signal words present" || echo "PASS: no AI-signal words"
   

2. 标题公式——确认已记录标题公式：

   grep -q "Bug Class.*in.*Endpoint.*allows.*attacker" SKILL.md && echo "PASS: title formula present" || echo "FAIL"
   

所有测试都用于验证报告撰写准备情况。

---

常见问题

• 把执行摘要当作事后补充——这是高管唯一会读的部分。开篇应突出业务影响，而非技术细节。
• 使用「可能」和「或许」等措辞——这些词会让发现显得只是理论推测。使用「允许攻击者……」和「演示证明……」。
• 缺少复现步骤——如果没有能触发问题的确切 HTTP 请求，「我在 /search 上发现了 XSS」就毫无价值。
• CVSS 与影响不符——声称严重性为 Critical，却描述 Low 影响，会损害可信度。CVSS 评分必须与已演示的影响相符。
• 报告过长——分诊人员会快速浏览报告。正文应控制在 600 个词以内。详细证据请使用附件。
• 措辞听起来像 AI——「全面」「利用」「无缝」「确保」等词会让内容显得由 AI 生成。表达要直接、自然。

---

相关技能与串联流程

• triage-validation——决定是否撰写报告时使用。工作流原语：在 triage-validation 的 7-Question Gate 通过前，绝不要打开此技能；未通过关卡的发现应直接放弃，而不是写成报告。
• 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）。

---

操作人员须知

基于真实任务对供应方法论所做的补充。内容来自真实的授权任务，以及本仓库 31+ 个技能领域实时测试中的第 2 阶段验证。上游方法论涵盖 WHAT；这一层则涵盖 实际奏效的情况和失效模式。

实际应用标题公式

<asset> | <bug class> | <impact>——三个组成部分，不加废话。分诊人员看标题大约只用三秒，并据此安排队列顺序。

• BAD：「在 /api/users 上有一项有趣的发现」
• BAD：「API 中的 IDOR 漏洞」
• GOOD：「已认证用户可利用 /api/users/{uid} 上的 IDOR 泄露管理员邮箱和角色」
• GOOD：「未经认证的用户可利用 /preview?url= 上的 SSRF 访问 AWS 元数据 [REDACTED_IP]」

不好的标题会被最后打开，好的标题会被最先打开。同一个发现，队列位置不同，分诊日期不同，付款速度也不同。

分诊人员实际会读什么

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

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 高危，因为跨租户数据泄露涉及机密性：高。”
3. 引用与发现相符的平台自身 VRT 条目。 不要反驳平台；应按其规则提出申请。

在一次经授权的漏洞赏金活动中，通过严重性申请段落，默认 P4 的发现被提升至 P3。严重性不会自动提升——你必须在正文的第一个部分中提出申请，并给出有依据的理由。

证据轮换

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

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

通过链接 evidence-hygiene 参阅完整的采集与脱敏流程。

技能与公开文档中的数据卫生

技能、README 文件和任何面向公众的文档都必须完全不包含特定对象信息。切勿包含：

• 公司名称、域名或品牌名称
• 员工姓名、邮箱或个人身份标识
• 与可识别目标相关的具体漏洞详情
• 项目 ID、存储桶名称或内部主机名

请改用不含特定对象信息的模式：

BAD:  "customer.example had PHPInfo + XMLRPC -> RCE"
GOOD: "e-commerce target had PHPInfo + XMLRPC -> RCE"

BAD:  "[email protected] exposed via REST API"
GOOD: "corporate email pattern exposed via REST API"

BAD:  "customer.example MySQL 3306 OPEN"
GOOD: "healthcare SaaS target had MySQL 3306 exposed"

针对每个目标的完整发现详情应存放在操作人员选定的 OUTPUT_DIR 下。技能应保存模式、技术和方法，而非活动证据。

编写技能或 README 时：

• 使用 TARGET、example.com、evil.com 作为占位符
• 使用行业级描述（例如“医疗 SaaS”“电子商务”“政府门户网站”）
• 使用汇总统计数据（例如“约 7-8% 的 WP 网站存在 CORS 问题”），而非针对具体目标的细节
• 如果必须使用真实案例，请删除所有可识别信息：将域名替换为行业描述，删除邮箱，并将项目 ID 匿名化

各平台模板——差异说明

平台	语气	必需结构	严重性机制
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 — 当 Phase 5 的报告撰写步骤开始时使用。工作流基础组件：Phase 5 会调用 /report，加载此技能以获取特定平台的模板（H1 / Bugcrowd / Intigriti / Immunefi）。