渗透报告模板

渗透测试报告写砸了，渗透比不做测试还危险。报告我见过一份报告，模板整整十二页，渗透漏洞列表长得像超市小票，报告结果开发团队看完只回了一句：“所以我们要先修哪个？模板”——那份报告里，高危、渗透中危、报告低危排得整整齐齐，模板但没有一句话说清楚哪个漏洞能直接拿到数据库权限。渗透客户花钱买的报告是风险判断，不是模板漏洞清单。

报告的渗透第一页不该是目录。把最要命的报告东西放最前面。比如：“通过前台SQL注入，模板已获取管理员密码哈希，解密后登录后台，可上传webshell。”一句话，决策者立刻知道这事有多急。我习惯在开头写一个“攻击路径摘要”，用三到五步描述从外网到核心数据的完整链路。每一步后面标注利用的漏洞编号和影响范围。这不是炫技，是让技术负责人和安全负责人能在三十秒内对齐认知。

漏洞描述部分，别抄扫描器输出。扫描器说“可能存在SQL注入”，你得验证并写清楚：参数是哪个、payload长什么样、返回了什么数据库报错、能不能union查询、当前数据库用户是不是sa。有一次我写“id参数存在布尔盲注，通过id=1 AND 1=1与id=1 AND 1=2返回页面差异确认”，开发看完直接定位到代码行。细节到位，修复成本砍半。

风险等级别只依赖CVSS。CVSS 7.5的漏洞如果在内网且需要认证，实际风险可能低于CVSS 5.0但无需认证的远程命令执行。我在报告里会加一列“实际利用难度”，分“脚本小子可用”“需要一定经验”“需要内部知识”三档。客户的安全团队一看就明白优先级怎么排。有个客户曾把某个中危漏洞排在高危前面，就因为那个漏洞的利用工具在GitHub上已经公开了。

修复建议要具体到代码层面。别写“对输入进行过滤”，写“在LoginController.java第47行，将String sql = "SELECT * FROM users WHERE name='" + name + "'"改为PreparedStatement，参数用?占位”。如果不知道具体文件，至少给出函数名和参数名。我还会附上修复后的验证方法：比如“修复后发送name=admin'--应返回登录失败而非数据库错误”。这样开发自测就能闭环。

附录里放什么？很多人放一堆扫描截图，没用。我放三样东西：一是完整的HTTP请求与响应原始报文，方便复现；二是时间线，记录每个漏洞的发现时间、验证时间、报告时间；三是工具列表及版本，比如Burp Suite 2023.10.2、sqlmap 1.7.2。有一次客户质疑某个漏洞的真实性，我直接调出附录里的原始报文，对方当场确认。

最后说个反直觉的点：报告里要留“未验证的怀疑点”。比如“在/api/v2/export接口观察到异常延迟，疑似存在盲注但未进一步测试，建议内部复查”。这比假装什么都测透了更诚实。渗透测试永远有盲区，把盲区标出来，客户反而更信任你的专业判断。我见过一份报告，末尾写了句“本次测试未覆盖移动端App的本地存储加密”，客户后来专门为这个点追加了预算。

写报告不是交作业。它是你作为攻击者留给防御者的作战地图。地图画得越准，防守方越省力。别让格式和套话淹没真正重要的东西——那个能直接打穿系统的漏洞，值得你用最直白的语言写在最前面。