一份渗透测试报告，渗透真正有价值的测试部分从来不是漏洞列表，而是报告攻击路径的还原。上周我拿到一份某电商平台的总结测试报告，客户运维团队看完只问了一句：“你们怎么从客服系统跳到支付数据库的渗透？”——这个问题恰好说明报告写到位了。漏洞本身是测试静态的，路径才是报告动态的、可复现的总结风险。

报告开篇直接放了一张拓扑图，渗透标注了三个跳板节点。测试第一个入口是报告客服后台的弱口令，admin/123456，总结听起来离谱，渗透但真实环境里这种配置并不少见。测试攻击者从这里拿到工单系统的报告读取权限，工单里存着用户手机号和部分订单号。接下来是关键一步：工单系统与内部OA共用一套LDAP认证，通过工单系统的一个SSRF漏洞，可以读取OA的API接口文档。文档没做权限控制，直接暴露了内部接口的调用方式。

从OA到支付数据库的跨越靠的是一个遗留的调试接口。这个接口在测试环境里用来同步订单状态，上线时忘了关。它接受一个订单号参数，返回完整的支付流水，包括银行卡后四位和交易金额。接口没有鉴权，只要知道订单号就能查。攻击者从工单里拿到订单号，批量请求这个接口，数据就出来了。

整个链条里，单个漏洞的CVSS评分都不算高。弱口令7.5分，SSRF 6.8分，未授权访问7.2分。但组合起来，从外网到核心支付数据，只用了四步。报告里我特意用红色虚线标出了这条路径，旁边写了一句：“修复任一节点即可阻断，但建议优先处理调试接口。”客户后来反馈，他们先关了调试接口，再改LDAP配置，最后才处理弱口令——因为调试接口的修复成本最低，影响面最小。

报告里还记录了一个有意思的细节。测试过程中，客服系统的登录页面有个验证码，但验证码的答案直接写在HTML注释里。。这种低级错误在代码审计里经常遇到，开发图省事，测试完没删。我把它单独列出来，标注为“信息泄露”，虽然不直接导致入侵，但能帮攻击者省掉爆破的功夫。

漏洞复现步骤我写得比较细，每一步都附了请求和响应截图。比如SSRF那一步，我贴了Burp的抓包记录，参数是url=http://internal-oa/api/docs，返回的JSON里包含接口列表。客户的技术负责人说，他们照着报告里的步骤，在自己的测试环境里完整复现了一遍，确认了路径的真实性。这种可复现性比漏洞评级更重要。

报告最后没有写“建议加强安全意识”这种空话。我列了三条具体动作：一，关闭所有非生产环境的调试接口，用Nginx层做白名单；二，LDAP认证增加IP段限制，工单系统只能从指定网段访问OA；三，客服系统强制密码复杂度，验证码改为后端生成并校验。每条都写了责任人和预计工时。客户按这个清单排了修复计划，两周后复测，路径断了。

渗透测试报告的本质是一份攻击剧本。读报告的人需要知道：如果我是攻击者，我会怎么走；如果我是防守方，我该在哪里设卡。漏洞列表是素材，路径才是故事。把故事讲清楚，报告就及格了。