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 自带完整判据）
分两层：硬门（所有漏洞必过，缺一不报）+ 按类型命门（不同类型的"关键钥匙"）+ 质量项（尽力，不卡报告）。
硬门（所有漏洞必过，缺一不报）
- 先证伪（正常功能排除） — 先假设"这就是正常功能"，主动跑否定实验去推翻它：未授权→用
zzz不存在<时间戳> 跑同协议，看是不是 catch-all/公开/样例；越权→用合法 body 重测排除 400 假阳性、POST 排除 SPA 回退；SSRF→确认是不是服务端正常连接功能而非越过边界。证伪不掉，才可能是漏洞；证伪掉了，作废不报。
- PoC 可复现 — 能直接粘贴原始 HTTP 请求块（从抓包工具原文复制），不需要额外解释上下文。
- 真实业务影响（链路终局，危害要实际打出来） — 拿到别人的 ≥3 个敏感字段真实数据 / 操作真实生效改了别人业务状态 / 凭证实际访问到敏感内容。是数据泄露/账户接管/资金损失/服务端 RCE/内网横向的终局结果，不是中间信号（文档/token/拓扑泄露不是终点），不是"理论上有风险"。打不出实际危害 = 信号作废 = 不报。
- 服务端/权限边界确认 — 是服务端或权限边界问题，不是浏览器 JS 假象/调试功能/页面渲染。
- 类型命门 — 命中下方按类型命门表中对应行的硬条件。
- 链式追问到终局 — 已顺根因穷举同类接口 + 纵深追到危害边界（不是问一层就交），或已记录"为什么到此为止"。
按类型命门表（不同类型，关键钥匙不同）
| 漏洞类型 | 命门（硬条件） |
|---|
| 数据泄露 | 别人的数据 + ≥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）
B. 类型与前提（平台明文不收的类型，一票否决）
C. 案例与证据
D. 投递纪律（诚信红线）
核心写作标准：双重可读（每份报告都要同时做到）
报告必须同时满足两个维度，缺一份都不合格：
① 小白可复现 —— 让完全不懂安全的审核者也能照着一步步复现出来：
- 每个 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）。成稿流程开始时先检测当前环境，按三级阶梯走：
- 自动检测：检查当前可用工具列表，凡是能"打开 URL + 截图"的都算——Playwright MCP、chrome-devtools MCP、Puppeteer MCP 等浏览器类 MCP 提供的 navigate/screenshot 工具。检测到就直接用，每个 Step 由 AI 打开原始 URL 自动截图，无需询问用户。
- 没有工具 → 给建议：明确告诉用户"检测到当前环境没有浏览器工具，无法自动截图"，并给出推荐安装命令（如
claude mcp add playwright -- npx @playwright/mcp@latest）。用户愿意装 → 装完回到第 1 级全自动。
- 用户不装 → 人工供图：每到一个需要截图的 Step，明确告诉用户"请把这一步的抓包工具/浏览器截图保存为
shots/step<N>_<说明>.png"，用户放好后嵌入对应位置。禁止因为没工具就静默跳过截图、用"此处应有截图"占位、或用文字描述代替。
用户也不提供截图 → 报告不满足截图铁律，明确告知"缺真实截图的报告大概率被平台驳回"，由用户决定是否继续，不偷偷降级成无图报告。
提交前自检（交稿前必过）
去 AI 腔检查（交稿前必过）
平台审核开始用 AI 检测+人工直觉筛报告，模板化 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。