内容摘要：上周三晚上十一点，我盯着漏洞扫描报告里那个红得刺眼的“高危”标记，后背有点发凉。那是个SQL注入点，就在我们官网的搜索框里，参数没做任何过滤。攻击者只要在输入框里敲一段精心构造的代码，就能把整张用户表

上周三晚上十一点，网站我盯着漏洞扫描报告里那个红得刺眼的存安“高危”标记，后背有点发凉。全漏那是洞整个SQL注入点，就在我们官网的改报告写搜索框里，参数没做任何过滤。网站攻击者只要在输入框里敲一段精心构造的存安代码，就能把整张用户表拖走——包括那几万条注册手机号和密码哈希。全漏这不是洞整演习，是改报告写真真切切悬在头上的刀。

写整改报告，网站别急着堆技术细节。存安领导要看的全漏是三件事：这漏洞会造成什么后果，你怎么堵上的洞整，以后怎么不再犯。改报告写开篇就得把这三点砸实了。我见过太多人第一页全是漏洞原理科普，翻到第三页才看见“已修复”三个字，那报告基本白写。

先说漏洞描述，别照抄扫描器的英文原话。用大白话讲清楚：哪个系统、哪个页面、什么类型的漏洞、攻击者能干什么。比如“官网搜索框存在SQL注入漏洞，攻击者可通过构造恶意请求获取数据库全部用户信息，包括手机号、邮箱及密码加密后的哈希值”，比“XX系统存在基于时间的盲注”强一百倍。后者是给机器看的，前者才是给人看的。

接着写修复措施，这部分要具体到能验证。别写“已加强输入验证”这种空话，要写“对搜索参数增加了白名单校验，只允许字母数字及下划线，长度限制在50字符以内；同时改用预编译SQL语句，彻底切断参数拼接”。最好附上关键代码片段或配置文件修改前后的对比截图。我当时把修复后的代码贴上去，又在旁边补了一句“已通过sqlmap复测，注入点不再生效”，这一句话比任何技术名词都管用。

然后必须写影响范围评估。别糊弄，老老实实查日志。这漏洞上线多久了？有没有被外部扫描器探测过？有没有异常流量指向那个搜索接口？我当时翻了三个月访问日志，确认只有内网扫描器碰过，没有外部IP触发过恶意请求，心里才踏实了点。把排查过程写清楚，哪怕结论是“未发现被利用痕迹”，也比不写强。

再往下，是整改后的验证结果。这个环节最容易写成流水账。别只写“复测通过”，要写清楚怎么测的——用了哪些工具、测了哪些注入点、有没有做绕过尝试。我习惯在报告里附上一张复测截图，显示漏洞状态从“高危”变成“已修复”，旁边再用红笔圈出扫描时间。这种可视化证据，比文字有力得多。

最后写预防措施，这部分别贪大求全。写两三条能落地的就够了。比如“对所有对外接口统一接入WAF，并开启SQL注入防护规则”、“开发规范中强制要求数据访问层使用参数化查询”、“每两周做一次全站漏洞扫描，高危漏洞必须在48小时内修复”。别写“加强安全意识培训”这种没法量化的废话，领导看了只会觉得你在凑字数。

报告结尾别用“我们将继续努力”之类的收尾。直接给一个时间节点：“下周五前完成所有历史接口的梳理，同步更新安全编码规范并组织开发团队评审”。有日期、有动作、有责任方，这份报告才算真正闭环。

写整改报告这事，本质是跟漏洞赛跑后的复盘。你写得越实在，后面扯皮就越少。别怕暴露问题，瞒报才是最大的漏洞。