Skip to content
Back to skills

report

ASecurity

确认漏洞后产出正式 SRC/0day 提交稿 DOCX 报告的收口 skill。仅在漏洞已确认、准备成稿时使用——负责查重、过分层验证门、按固定 DOCX 骨架生成报告(Heading 2 章节 + Step 式 PoC + 内嵌真实截图)、语义化命名、放对目录、处理驳回追加。不负责挖掘/验证漏洞本身。TRIGGER:用户说"写报告/出报告/成稿/提交稿/生成漏洞报告",或漏洞已验证到位准备交付时;或 /report。EN: Turns confirmed vulnerabilities into submission-ready DOCX reports for SRC/0day platforms (verification gates, fixed layout, step-style PoC, mandatory real screenshots). Trigger on "write report" or /report.

  • 63 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added August 30, 2026
securitypythongojavashellsqlgitapidatabase

Works with

  • api
  • mcp

Security analysis

A100/100

Pro scans all 2 files and shows the line behind each finding

Scanned August 30, 2026

npx -y skills add v-yun/vuln-report-skill --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of report?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for report
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/v-yun-report/badge)](https://www.skillsdirectory.com/skills/v-yun-report)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: report
description: 确认漏洞后产出正式 SRC/0day 提交稿 DOCX 报告的收口 skill。仅在漏洞已确认、准备成稿时使用——负责查重、过分层验证门、按固定 DOCX 骨架生成报告(Heading 2 章节 + Step 式 PoC + 内嵌真实截图)、语义化命名、放对目录、处理驳回追加。不负责挖掘/验证漏洞本身。TRIGGER:用户说"写报告/出报告/成稿/提交稿/生成漏洞报告",或漏洞已验证到位准备交付时;或 /report。EN: Turns confirmed vulnerabilities into submission-ready DOCX reports for SRC/0day platforms (verification gates, fixed layout, step-style PoC, mandatory real screenshots). Trigger on "write report" or /report.
---

# report — 漏洞报告成稿收口

> **EN**: This skill turns confirmed vulnerabilities into submission-ready DOCX reports. The body is in Chinese because the target platforms (Chinese SRCs, CNVD/CNNVD, EDUSRC) require Chinese reports; the methodology is language-agnostic. See README.md for an English overview.

> 这是**薄编排层**,只做一件事:把**已确认**的漏洞写成可直接提交给审核方的 **DOCX** 提交稿。
> 漏洞怎么挖、怎么验证不在本 skill 范围;但"什么漏洞够格写成报告"的**分层验证门已内联在本文**,自成一体。

## 何时用 / 何时不用

- ✅ 用:漏洞已确认(硬门过了)、准备成稿交付、扩大危害后更新报告、被驳回后追加申诉。
- ❌ 不用:还在挖 / 还在验证 / 只有单点信号没到终局 → 继续验证,别急着开报告。

**前置铁律**:无 PoC = 不存在漏洞;影响没落地到链路终局 = 不写报告。P3 以下不写。

---

## 双重审查机制(第一道挖掘期快筛,第二道成稿前严审)

> 别把所有判断都攒到写报告前——那时才驳回,验证花的 token 全浪费了。第一道筛在**挖掘过程中**就跑,明显不够格的当场止损,根本不进报告候选;只有过了第一道筛的候选漏洞,才走到第二道完整验证门。

### 第一道:挖掘期信号快筛(轻量,遇到信号就跑,只花判断力)

信号 ≠ 漏洞。每遇到一个信号,先花几秒钟分三档:

| 档位 | 判据 | 动作 |
|------|------|------|
| **当场止损** | 只读到自己测试账号的数据;内容是公开页面/默认样例/模板;疑似 catch-all 路由(用 `zzz不存在<时间戳>` 同协议跑一次就露馅);只有版本号/指纹/安全头缺失这类无危害信息 | 不再追、不进候选、不记录为漏洞 |
| **待验证信号** | 有异常但还没打到终局 | 继续往"别人的数据 / 真实生效的操作 / 命令执行回显"方向追;追不到就停在信号,不写报告 |
| **候选漏洞** | 已看到他人真实数据 / 操作真实生效 / 命令执行回显等终局迹象 | 标记候选、补证据,成稿前过第二道 |

第一道的目的是把"注定写不成报告的方向"在深挖之前砍掉,省的是整段验证的 token。

**第二道:成稿前分层验证门** —— 候选漏洞走到写报告这一步时,过下方完整判据(硬门 + 类型命门 + 质量项),缺一不写。

---

## 分层验证门(成稿前必过,本 skill 自带完整判据)

> 分两层:**硬门**(所有漏洞必过,缺一不报)+ **按类型命门**(不同类型的"关键钥匙")+ **质量项**(尽力,不卡报告)。

### 硬门(所有漏洞必过,缺一不报)

0. **先证伪(正常功能排除)** — 先假设"这就是正常功能",主动跑否定实验去推翻它:未授权→用 `zzz不存在<时间戳>` 跑同协议,看是不是 catch-all/公开/样例;越权→用合法 body 重测排除 400 假阳性、POST 排除 SPA 回退;SSRF→确认是不是服务端正常连接功能而非越过边界。**证伪不掉,才可能是漏洞;证伪掉了,作废不报。**
1. **PoC 可复现** — 能直接粘贴原始 HTTP 请求块(从抓包工具原文复制),不需要额外解释上下文。
2. **真实业务影响(链路终局,危害要实际打出来)** — 拿到别人的 ≥3 个敏感字段真实数据 / 操作真实生效改了别人业务状态 / 凭证实际访问到敏感内容。是数据泄露/账户接管/资金损失/服务端 RCE/内网横向的**终局结果**,不是中间信号(文档/token/拓扑泄露不是终点),不是"理论上有风险"。打不出实际危害 = 信号作废 = 不报。
3. **服务端/权限边界确认** — 是服务端或权限边界问题,不是浏览器 JS 假象/调试功能/页面渲染。
4. **类型命门** — 命中下方按类型命门表中对应行的硬条件。
5. **链式追问到终局** — 已顺根因穷举同类接口 + 纵深追到危害边界(不是问一层就交),或已记录"为什么到此为止"。

### 按类型命门表(不同类型,关键钥匙不同)

| 漏洞类型 | 命门(硬条件) |
|---------|--------------|
| 数据泄露 | 别人的数据 + ≥3 敏感字段 + 非公开/非样例/非模板;自己测试账号数据 ≠ 漏洞 |
| 越权 / IDOR | **A/B 交叉证明**:A 拥有的资源,B 的 token 能读/改;只读到自己不报 |
| RCE / 命令执行 | 真实命令执行实证;"别人的数据"对 RCE **天然不适用**,能执行命令本身就是危害 |
| SSRF | 服务端发出(回调 UA 证明 Java/Go/Python,非客户端 JS fetch)+ **有官方靶场必须先过靶场(不过不收);无靶场必须回显内网数据**(云元数据/内网服务 banner/内网页面内容)。**DNSlog 只是其中一步**:出网响了 = 敲门砖,必须继续打到回显/危害终点,仅 dnslog 记录直接交 = 半成品不收 |
| 认证绕过 / ATO | **任意**用户可绕过/接管,不只证明自己能登自己号;OAuth/JWT/密码重置逻辑要 A/B 双账号证明 |
| 业务逻辑 / 资金 | 操作**真实生效** + 影响的是他人业务状态(金额/订单/状态机跳转),不是自己测试数据 |
| 文件上传 | **造成实际效果才算**:webshell 可执行(getshell)或存储型 XSS 触发(HTML/SVG 被服务端解析);只传上去/能访问但纯存储不解析 = 不成立 |
| 注入 (SQL/NoSQL/SSTI/XXE) | 有确定输出/副作用证明(错误回显、时间差、OOB marker),不是"报错就报";**SQL 注入最低共识 = 注出库名 `database()`**(盲注需时间差 + 库名内容,特殊情况另议) |

### 质量项(不卡报告,写进报告说明即可)

- **否定实验**:对存疑结论写出"如果这不是漏洞,最可能的解释"并执行证伪。
- **跨环境复现**:两个 IP/浏览器/账号/机器之一复现。
- **WAF/防护绕过已记录**:有防护→试了哪些绕过→结果;无防护→说明确认方式。

### 0day / 通用产品漏洞:收录审查门(按 0day 成稿前必过)

> 各收录平台(CNNVD/CNVD/补天/厂商 SRC 等)规则取**最严并集**,任一否决项命中 = 不按 0day 成稿。

**A. 版本与公开性(最新版不带洞 = 不是 0day)**
- [ ] 漏洞在厂商**当前最新版仍存在**:GitHub 漏洞文件引入时间 vs 最新 release tag 日期对比 / 官网下载最新版实测 / 厂商安全公告与 changelog 检索,三选一。只在未发布分支或老版本存在 → 不按 0day 成稿
- [ ] 老版本洞例外:最新版已修但老版本测绘存量巨大 → 报告必须写清受影响版本范围 + 修复版本 + 修复 commit/版本对比证据
- [ ] 未完全公开:无 CVE/CNVD/CNNVD 编号、无公开 PoC/分析文章/厂商公告;OEM/同源源码产品任一已公开 = 全线视为公开
- [ ] 产品本身三年内官方有更新维护(废弃/测试/演示系统不收)

**B. 类型与前提(平台明文不收的类型,一票否决)**
- [ ] 非通用型弱口令/默认口令;非"需账号密码/验证码登录后台为前提";非用户配置不当/主动暴露;非沙箱预期功能 RCE;非单纯盲注/仅延时无明确危害;非未越权的 DOM/反射 XSS
- [ ] 同根因多个同类问题并为一洞;同系统相似类型历史只发一次
- [ ] 危害已实证(数据/权限/RCE 终局),非"存在可能性"

**C. 案例与证据**
- [ ] 黑盒底线 ≥10 互联网案例(3 个详细 + 10 个以上其他);目标高奖金档位需更多独立 IP(按目标平台档位对齐,成稿前如实告知预期档位)
- [ ] 证据 2 周内(事件型 3 天内)+ 保留时间戳;案例 IP 提交时现场验证存活
- [ ] 测绘语法精准 + 独立 IP 数 + 统计来源与时间进报告
- [ ] 白盒另需:代码审计/逆向过程 + 准确版本号 + 当前最新版本证明 + 待测试程序

**D. 投递纪律(诚信红线)**
- [ ] **一洞只交一家**(多交会被各平台拉黑/信用评估)。交前定主平台路由:未授权前台 RCE → 通用漏洞高奖金平台;认证绕过/文件读取/凭证泄露等非 RCE → CNNVD/CNVD 类;老版本洞 → CNVD/CNNVD 类;教育行业资产 → EDUSRC
- [ ] 附件齐套:Word 报告 + POC/EXP + 待测试程序 + 复现录屏(按目标平台要求)

---

## 核心写作标准:双重可读(每份报告都要同时做到)

报告必须**同时**满足两个维度,缺一份都不合格:

**① 小白可复现** —— 让完全不懂安全的审核者也能照着一步步复现出来:
- 每个 Step 让人看懂:**做什么** → **在哪个 URL 操作** → **实际看到什么结果**;不跳步、不省略上下文、不用只有安全圈才懂的黑话而不解释。
- 但"能复现"≠啰嗦:背景交代一两句够用,禁止八股标签和填充语(见下方「简洁硬规」)。
- PoC 给可直接复制粘贴的完整原始 HTTP 请求块(从 Burp/Yakit 等抓包工具原文复制,**不放 curl**),配真实截图,照做就能看到同样结果。
- 逻辑连贯顺滑,像一条能走通的路,不是散落的证据堆。

**② 技术不空洞** —— 该有的技术深度一分不能少:
- 讲清**根因**:为什么会有这个漏洞(鉴权缺失在哪一层/逻辑缺陷在哪/信任边界哪里破了)。
- 讲清**原理**:接口如何工作、参数如何被利用、鉴权差异如何证明、payload 为何生效。
- 给出**关键技术证据**:真实请求/响应字段、路由映射、代码片段、鉴权头对照、规模化数据统计。
- 结论有据可查,不是"我觉得有问题",而是"因为 X 技术事实所以是 Y 漏洞"。

> 判断标准:一个产品经理照着能复现,一个安全工程师看了觉得技术扎实、无懈可击。两个都过才算合格。

---

## DOCX 版式规格(格式基准,不得自由发挥)

**生成方式**:python-docx。从同目录 `template.docx` 复制起步(已含全部样式),逐节 append。**不要**手写 HTML 再转换。

**样式**(模板已内置,直接用样式名):
- 正文 `Normal`(微软雅黑 11pt);章节标题 `Heading 2`(13pt 加粗);Step 标题 `Heading 3`;bullet 用 `List Bullet`。
- **全文统一黑色**:模板已去除 Word 默认主题蓝(Heading/Title/边框全部 000000),标题与正文颜色一致。生成时不得再给任何文字/边框手动设置彩色。
- 不用表格堆排版、不用卡片/配色——审核接受的是朴素的线性文档。

**章节骨架**(Heading 2 按此顺序,可选节用〔〕标注):

| 章节(Heading 2) | 内容要求 |
|------|---------|
| 漏洞名称 | 一句话:`资产 存在 漏洞类型 + 终局危害 漏洞` |
| 漏洞等级 | 严重/高危/中危 + 一句定级依据(标题就叫"漏洞等级",不加"自评"等后缀) |
| 漏洞类型 | 类型全称 + CWE(如有) |
| 漏洞影响资产 | 主资产域名/范围 + API 路径 + 关联资产 |
| 漏洞URL | 纯 URL 列表,一行一个,**不写注解**("它是干什么的、参数怎么被利用"归漏洞描述讲) |
| 漏洞描述 | 功能如何工作 → 根因 → 攻击者能干什么(编号列点)→ 关键验证结论(规模数字/IP/已确认事实) |
| 〔测试账号与会话上下文〕 | 测试角色、account_id、复验用 Cookie/token(注明"过期重登替换即可") |
| 漏洞复现步骤(POC) | 见下方 Step 规格 |
| 漏洞危害 | 危害枚举(编号,每条带已验证事实)+ 影响数据明文样本(便于审核直接验证,不打码)+ 边界声明(未做的越权动作)。就这一节,不另开"影响数据示例" |
| 修复建议 | 具体可执行(编号,含网段/参数级细节;根因已在漏洞描述讲清,不另开"根因分析"节) |

报告正文到「修复建议」为止。**「复验清单」「建议评级说明」「实际攻击场景」「根因分析」「漏洞关键点」「影响数据示例」一律不单开节**——复验走上方分层验证门(内部动作);定级理由只保留「漏洞等级」里的一句;攻击链时序和根因并进漏洞描述;数据样本并进漏洞危害。

### 0day / 通用产品漏洞:走通用型漏洞报告模板

**成稿前先过上方「0day 收录审查门」**(A 版本公开性 / B 类型前提 / C 案例证据 / D 投递纪律,任一否决项命中不成稿)。审查门没过 = 不按 0day 交付,回挖掘或换平台通道。

0day、通用产品漏洞**不用上面的 SRC 章节骨架**,一律按通用型漏洞报告模板成稿。章节顺序:

漏洞报告标题 → 漏洞发现时间 → 漏洞技术类型 → 漏洞描述(两段式:第一段产品介绍、第二段成因+危害)→ 漏洞危害 → 漏洞厂商全称 → 已知受影响产品及版本(附资产-产品强相关证明截图)→ 互联网资产证明(精准测绘语法 / 独立 IP 数量文字描述 / 测绘平台截图)→ 1、漏洞技术细节(完整 PoC:原始请求块+每步真实截图;触发条件)→ 2、复现证明(黑盒:3 个详细案例 + 10 个以上其他受影响目标)→ 3、修复方案(厂商修复 + 运维临时方案)→ 4、备注(边界声明)。

- 案例 IP 必须**提交时现场验证存活**,宁换不凑(云上动态实例隔天就会掉线,演示目标死掉会导致审核复现失败)。
- 测绘数据用测绘平台 API 取**当日口径**(独立 IP 数/国家分布/端口分布),测绘平台截图贴结果页。
- PoC 请求块用等宽字体段落;每步真实截图、不打码、不放 curl 等既有硬规全部沿用不变。

**Step 规格**(POC 章节内,每步严格这个结构):

```
[Heading 3] Step N:一句话标题
[Normal] 一两句话交代这步做什么、在哪个 URL 操作(必要背景并入此处,不写"为什么:"标签)
[Normal] PoC:
[Normal] POST /path HTTP/2          ← 抓包工具原始请求块整段贴入(纯文本段落,不打码)
Host: ...
...
[Normal] 结果: 一句结论(证明了什么)。**不贴返回数据包原文**——响应内容以截图为准,文字只写结论
[Normal] 截图(说明这是什么的截图):
<内嵌图片>                          ← docx.add_picture,紧跟"截图"段
[Normal] 图:xx_说明.png            ← 图注一句
```

**简洁硬规(违反即返工):**
- **禁止"为什么:"/"操作:"这类八股标签**,Step 用一两句自然语言交代动作即可;背景知识确有必要才写,能省就省。
- **同一事实全文只出现一次**:IP 清单、测绘数字、版本号、实证结论,写在哪一章就只在哪一章;其它章节需要时用"见漏洞描述"式指代,不整段复读。
- **相邻章节不得内容重叠**:漏洞描述讲清链路和结论后,后续章节需要时用"见漏洞描述"式指代,不整段复读;漏洞危害每条一行事实,不展开复述攻击过程。
- **一句话能说完的不写三句**:删掉"值得注意的是""也就是说""换句话说"类填充语,删掉对截图内容的文字复述(截图就在下面)。

**去AI腔硬规(违反即返工):** 报告要读起来像安全工程师手写的,不像模型生成的。
- **内部方法论黑话不进报告**:证伪/否定实验/同根因/命门/链路终局等过程词一个都不出现。这些结论用自然语言陈述事实("同框架其余接口鉴权正常,排除是公开查询功能"),不点名方法论。
- **禁止破折号拖尾解释**:结果一句话写完,不用"——证明了……/——即……/——说明……"收尾;结论确有必要时独立成短句。
- **禁止形容词渲染**:删掉"极具迷惑性""防骗难度极大""恶性竞争""天然构成"类修饰,只摆事实,严重性由审核者自己判断。
- **禁止截图元描述**:不写"下图为浏览器内实时请求后将响应转表格展示"这类关于截图本身的说明;截图处只有"截图(内容):" + 图片 + 一句图注。
- **bullet 不强行"主题词:"排比**:一事一句自然陈述,类别前缀只在确有助分类时用。
- **不单独开节游说评级**:「建议评级说明」不进报告(重申);定级依据只在「漏洞等级」留一句,升级理由融进漏洞危害的事实里。

---

## 成稿流程(按序执行)

### 第 0 步:查重(写之前必做,命中重复就停)

写任何新报告前,先 Glob/Read 目标单位的报告目录,按**四项**查重:

```
资产(同域名/IP)  根因(同一鉴权缺失/同一逻辑缺陷)  接口/功能点  影响面
```

- 四项高度重合 → **不新写**。要么作为原报告的补强(见第 5 步),要么换资产/换漏洞类型。
- 只重合资产但根因/影响不同 → 可新写,但报告里说明与已有报告的区别。

### 第 1 步:过分层验证门(判据见本文「分层验证门」节)

逐条打勾,硬门缺一不写:

```
[ ] 硬门0 证伪:假设"这是正常功能"并跑了否定实验,证伪不掉
[ ] 硬门1 PoC 可复现:能直接粘贴原始请求块,不需额外解释
[ ] 硬门2 危害是链路终局:资金/数据/接管/RCE/横向,不是中间信号
[ ] 硬门3 服务端/权限边界确认:不是浏览器 JS 假象/调试/渲染
[ ] 硬门4 命中类型命门(见上方按类型命门表对应行)
[ ] 硬门5 同根因接口穷举完、纵深追到边界,或记录"为什么到此为止"
[ ] 质量 否定实验:对存疑结论写出"如果这不是漏洞最可能的解释"并证伪
[ ] 质量 跨环境/跨账号/跨IP 至少一种复现
[ ] 质量 WAF:有防护记录绕过;无防护说明确认方式
[ ] 截图 每一步都有真实截图(浏览器打开原始 URL / 抓包工具实际响应,后台截图不抢前台),无一处自造渲染
[ ] 双读 小白照着能复现(操作→PoC→结果)且技术不空洞(根因+原理+关键证据)
```

硬门全过 → 写。质量项缺 → 不卡报告,但报告里说明。

### 第 2 步:生成 DOCX

复制 `template.docx` → python-docx 按「DOCX 版式规格」逐节填充。要求:
- 每个 Step 的截图用 `doc.add_picture(png路径, width=Inches(6))` 内嵌,紧跟"截图(...):"段落。
- PoC 请求块保持等宽可读:整块作为独立 Normal 段落(可用单个段落内换行),**不打码**。
- 数字、IP、marker、时间等所有事实**必须与截图/原始日志逐字一致**——写完回读截图核对一遍。凭记忆写数字极易出错(真实教训:一份报告里 DNSLog 数字凭记忆写了四处,全错,复核时才抓出来)。

### 截图铁律(最高优先级,绝不违反)

**报告每一步都必须配真实截图,绝不允许自己 PS/仿造/手绘渲染效果。**

- 截图来源只能是:浏览器打开目标原始 URL/响应后截图(用浏览器自动化工具的**后台截图**能力)、抓包工具实际请求/响应的证据(文本块或详情面板截图)。
- 凡绕过限制后能在浏览器直接打开渲染的图片/视频/页面/文件/JSON 响应 → **必须用浏览器打开原始 URL 截图**放进报告。
- 每个 Step 的关键结果都要有对应截图,让审核者能看到"我确实在真实目标上看到了这个"。
- **唯一例外**:目标内容客观无法在浏览器渲染时,才允许离线渲染/转存,并在报告里**明确写出为什么无法用浏览器直接截图**。
- PoC 数据包以文本完整保留即可,审核方会另行核对,不强制截图(但有请求/响应详情截图更好)。

#### 截图行为纪律(不打扰用户 + 证据可用,必守)

- **全程后台截图,禁止抢前台**:截图过程不能打断用户当前操作,任何窗口都不应被弹到前台。
  - 浏览器截图:用 headless 模式或 CDP 类后台截图(Playwright headless、`Page.captureScreenshot` 等),**禁止**把浏览器窗口激活/聚焦到前台。
  - 抓包工具界面截图(确有必要时):用后台窗口截图(如 Windows 下 PrintWindow 按窗口句柄抓图),**禁止** SetForegroundWindow / Activate / 模拟点击把 Burp/Yakit 等窗口拉到前台。
- **数据包证据优先文本块**:请求/响应一律以原始文本块嵌入 PoC(照抄抓包工具原文),不依赖工具界面截图。确实要截工具界面时,必须打开**数据包详情的 Request/Response 面板**再截——**禁止只截历史列表**(列表里没有包内容,审核无法核对,等于没截)。
- **工具中立**:Burp Suite / Yakit / Reqable / mitmproxy / Caido 等任何抓包工具均可,报告里是"原始请求块",不绑定具体工具。

截图 PNG 统一放临时目录 `shots/`(与 DOCX 同目录)。图片已内嵌 DOCX,**报告成稿交付后 `shots/` 随其它临时产物一并删除**,不长期留存。

#### 截图能力检测与降级(开工前先判定,三级阶梯)

**AI 不是天生会截图**——截图能力来自浏览器自动化工具(MCP)。成稿流程开始时先检测当前环境,按三级阶梯走:

1. **自动检测**:检查当前可用工具列表,凡是能"打开 URL + 截图"的都算——Playwright MCP、chrome-devtools MCP、Puppeteer MCP 等浏览器类 MCP 提供的 navigate/screenshot 工具。**检测到就直接用**,每个 Step 由 AI 打开原始 URL 自动截图,无需询问用户。
2. **没有工具 → 给建议**:明确告诉用户"检测到当前环境没有浏览器工具,无法自动截图",并给出推荐安装命令(如 `claude mcp add playwright -- npx @playwright/mcp@latest`)。用户愿意装 → 装完回到第 1 级全自动。
3. **用户不装 → 人工供图**:每到一个需要截图的 Step,明确告诉用户"请把这一步的抓包工具/浏览器截图保存为 `shots/step<N>_<说明>.png`",用户放好后嵌入对应位置。**禁止**因为没工具就静默跳过截图、用"此处应有截图"占位、或用文字描述代替。

用户也不提供截图 → 报告不满足截图铁律,明确告知"缺真实截图的报告大概率被平台驳回",由用户决定是否继续,不偷偷降级成无图报告。

#### 提交前自检(交稿前必过)

- [ ] 截图裁掉/遮盖:任务栏、本机用户名(含路径里的用户名)、其他浏览器标签页标题、书签栏、浏览器登录头像
- [ ] 请求块:不含与漏洞无关的个人标识(自己的 cookie/token/测试账号之外的隐私信息)
- [ ] PoC/正文:本地路径打码;IOC 按目标平台风控规则脱敏(有平台会因正文含特定 IOC 关键词整单拒收,被拦时二分定位脱敏)
- [ ] DOCX 元数据:作者/公司字段清空(生成后检查 docProps/core.xml)
- [ ] 报告内不留测试基础设施细节(代理、接码、邮箱服务商等)

#### 去 AI 腔检查(交稿前必过)

平台审核开始用 AI 检测+人工直觉筛报告,模板化 AI 腔会被降权/忽略。逐条过:

- [ ] **句式人化**:消灭"首先/其次/综上所述/值得注意的是"类连接词;长短句混排,允许口语化短句("这里直接就断了""这步没拦")
- [ ] **结构去模板**:不机械分"漏洞描述/漏洞危害/复现步骤"八股标题堆砌;按这个洞的叙事顺序走(怎么发现的→怎么验证的→打到什么)
- [ ] **删掉正确的废话**:危害段不写"攻击者可能利用该漏洞造成严重影响"类空话,只写实际打出来的东西
- [ ] **保留人味细节**:复现里带上真实判断痕迹("一开始以为是 X,测了 Y 排除"),这种否定实验过程 AI 腔写不出来,也是审核信任点
- [ ] **术语不翻译腔**:直接用 Burp/越权/getshell 等行话,不写"未经授权的访问漏洞(IDOR)"类教科书腔
- [ ] **列表节制**:满屏 bullet 是 AI 指纹;能一段话说清的不拆列表

### 第 3 步:语义化命名

文件名格式:`资产 存在 漏洞类型 漏洞.docx`

```
api.example.com 存在订单接口越权读取他人敏感信息漏洞.docx
console.example.com 存在文件上传绕过致存储型XSS漏洞_详细复现_2026-08-01.docx
```

阶段总结类可用:`单位SRC测试工作存在阶段总结报告.docx`

### 第 4 步:放对目录

报告统一放 `reports/` 下按单位/类型分目录:

| 目标 | 目录 |
|------|------|
| 企业 SRC | `reports/<单位>src/` |
| EDU | `reports/edu报告/`(根目录,不放子目录) |
| 0day / 通用产品 | `reports/0day/`(走通用型模板;报告内需含测绘语法、独立 IP 数、统计来源和时间) |
| 其他新单位 | 在 `reports/` 下新建 `<单位>src/` |

**只有确认漏洞的最终 DOCX 进这里**。JS/抓取归档/临时产物一律不进,任务结束即删。

### 第 5 步:更新 vs 驳回(两种截然不同的处理)

- **正常补强 / 扩大危害**(未被驳回)→ **融合改写**:把新证据整合进对应章节(描述/Step/危害/评级),必要时重排 Step、替换旧证据为更强证据,重新生成一版干净 DOCX。**不要**在底部堆"补充/追加/扩大说明"。
- **被审核驳回 / 需申诉**(明确被打回)→ **底部追加**:保留原报告上下文,在 DOCX 底部追加"驳回后补充说明/复核证据/申诉证据"(Heading 2 + 同样 Step 规格),不覆盖不另起;关键 PoC 保留在抓包工具的重放功能(Repeater 等)里便于复核。

### 第 6 步:收尾

- 只保留 DOCX;`shots/` 截图目录随对应临时目录/中间产物一并删除(图片已内嵌 DOCX;Markdown 稿、转换中间文件也删)。
- 确认漏洞后写复盘记录(什么信号命中的、哪步卡过、下次怎么更快)。

---

## 硬约束速查

- **每一步配真实截图**,绝不自己 PS/仿造渲染;来源只能是浏览器打开原始 URL / 抓包工具实际响应(后台截图,不抢前台)。PoC 数据包保留文本即可。
- 报告内证据**不打码**(提交稿要能被平台验证);普通聊天里可摘要。
- 只写能证明**非公开、他人数据、真实业务影响**的证据;公开内容/默认样例/自己测试账号数据 ≠ 危害,不写进危害。
- 单纯密钥/token 泄露不单独成报,只作高危链证据。
- CORS/安全头/版本号/Cookie 标志位/Self-XSS 不成报。
- 报告最终产物只有 **DOCX**,不留 HTML/Markdown。

Files in this skill

  • SKILL.md26.9 KB
  • template.docx19 KB

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…