漏洞分析报告模板

去年某电商平台被拖库，漏洞起因是分析一个三年前就被标记为“低危”的SQL注入点。开发团队当时觉得参数化了，报告没问题。模板结果新来的漏洞实习生写了个拼接查询，绕过了参数化。分析漏洞报告写了两页，报告修复花了四十分钟，模板但数据泄露的漏洞代价是八位数。所以别信“低危”两个字，分析漏洞分析报告的报告第一原则：任何能触达数据库的入口，都按高危对待。模板

漏洞标识与定位

报告开头别写“摘要”，漏洞直接写三行：漏洞编号（内部ID，分析别用CVE，报告那是给外人看的）、影响组件（精确到文件行号或API端点）、触发条件（比如“未登录用户构造POST请求”）。我见过一份报告写“某接口存在越权”，翻了三页才找到是哪个接口。浪费时间。直接上例子：

VULN-2024-017 组件：/api/v2/order/export?user_id=* 触发：普通用户A修改user_id为B，下载B的订单CSV

复现步骤要带“脏数据”

很多模板只写“1. 登录 2. 抓包 3. 改参数”。不够。真实复现需要说明环境差异。比如测试环境用了Redis缓存，生产环境没有，导致越权逻辑在测试环境不触发。我习惯在报告里加一段“环境备注”：数据库版本、中间件配置、甚至时区。上周一个SSRF漏洞只在UTC+8时区触发，因为日志切割脚本在午夜执行时重置了白名单。这种细节不写，开发修完说“复现不了”，来回扯皮三天。

根因分析：别只写“未过滤”

“未对用户输入进行过滤”是废话。要写清楚为什么没过滤。是框架自带转义被手动关闭了？还是用了`eval()`？举个例子：某Node.js项目用了`child_process.exec`拼接命令，开发说“我用了`escape-shell`库”。但库里有个已知绕过——反引号。根因是库版本低于1.2.3，且没开`windowsVerbatimArguments`。这种分析才能让修复方案落地。

影响评估：量化到“钱”或“人”

别说“可能泄露用户信息”。说“可读取全量用户手机号（约230万条），按黑市价每条0.5元，潜在损失115万元”。或者“可篡改任意订单金额，影响日均交易额80万元”。数字不一定准，但比“严重”两个字有说服力。我见过一份报告写“影响范围：全站用户”，开发反问“全站是多少？”——最后发现只影响注册超过3年的老用户，因为新用户走了另一套鉴权。

修复建议：给两个方案，标出代价

方案A：在Nginx层加正则拦截，5分钟上线，但会误杀带特殊字符的正常请求。方案B：重构参数解析逻辑，2天工作量，无副作用。报告里直接写“建议选B，A可作为临时热修”。别写“建议加强输入验证”这种空话。开发要的是能直接抄的代码片段或配置行。我通常附上一段diff，比如：

- const sql = `SELECT * FROM users WHERE id = ${ req.query.id}` + const sql = 'SELECT * FROM users WHERE id = ?' + db.query(sql, [req.query.id])

时间线与验证

漏洞报告不是写完就完了。加一列“验证状态”：发现时间、报告时间、修复时间、复测时间。复测必须用原始PoC，别用“类似请求”。我吃过亏：开发修了A参数，我复测时换了B参数，以为修好了，结果A还能打。最后在报告里加一句“复测需使用原始payload，并测试参数变体（大小写、编码、分块传输）”。

写报告的人得有点“被害妄想”。每个漏洞都当成对手已经利用了一半。模板是死的，但漏洞利用链是活的。上次一个XSS报告，我多写了一句“结合CSRF可劫持管理员会话”，开发连夜改了三个接口。别怕写多了，怕的是写少了。