证据与定级

一条合格的漏洞记录

五个要素，缺一个客户就会来问：

1. 位置。完整 URL、参数名、请求方法。不是「登录页面」，是 POST /api/login 的 username 参数。
2. 复现步骤。从打开页面到看到结果，一步步写。客户的安全工程师要能照着做出来。
3. 证据。请求包、响应包、截图。截图要能看出是哪个系统——带上地址栏或者系统标题。
4. 影响。能读到什么、能改什么、能控制什么。不写「可能导致数据泄露」这种，写「可读取 users 表中 12 万条手机号」。
5. 修复建议。具体到代码层面或配置层面。不写「加强输入校验」，写「用参数化查询替换字符串拼接，涉及 NewsDao.java 第 47 行」。

第五条最容易被糊。糊过去的结果是客户修不了，下一轮复测还在。

证据怎么留

测试过程中的截图和请求包，按漏洞编号归档：

evidence/
├── 01-sqli-news-id/
│   ├── request.txt
│   ├── response.txt
│   └── screenshot-01.png
├── 02-xss-feedback/
│   └── ...

请求包直接从 Burp 复制，别手打——手打容易丢 header，客户复现不了。

截图里如果带真实数据，打码。客户的数据出现在报告里，是另一个问题。

定级

定级是项目里最容易吵架的环节。客户想低，你想高，中间没有客观标准。

实际的做法是按「利用难度 × 影响范围」两个维度定，且把判断依据写进报告：

	影响小	影响大
无需前置条件	中	高
需要账号/交互	低	中

「无需前置条件」指不需要登录、不需要受害者点击。存储型 XSS 需要管理员点开，属于「需要交互」，所以定级比同位置的 SQL 注入低一档——除非它能打到高权限用户。

这套标准不完美，但它是可讨论的。客户不接受某个定级时，你们讨论的是「算不算需要交互」，而不是「我觉得严重你觉得不严重」。

一个具体的例子

同一个 XSS，三种写法：

• 「存在 XSS 漏洞」——客户不知道修不修。
• 「反馈功能存在存储型 XSS，管理员查看反馈时触发，可窃取管理员会话」——客户知道要修，但不知道多急。
• 「反馈功能存在存储型 XSS，管理员查看反馈时触发，可窃取管理员会话并进入后台（后台含全部客户订单数据）。建议本周内修复，修复方式：输出时对 HTML 转义，涉及 feedback-list.vue 第 32 行」——这个客户会当天安排人。

差别不在技术，在信息量。

自动化能做什么

日报、巡检报告这类东西，适合自动化：固定格式、固定指标、每天一遍。

适合自动生成的：资产变更、端口变化、证书到期、高危告警数量、补丁覆盖率。

不适合自动生成的：漏洞的影响描述、修复建议、定级。这三样必须人写，因为需要判断。

把不适合的部分也塞进模板，报告会变成一份没人读的表格——这比不交报告更糟，因为它消耗了信任。

参考

• 《一款自动化生成日报巡检报告工具》，公众号存档