渗透性测试报告

上周三凌晨两点，渗透试报某电商平台的性测风控系统突然报警：一个来自越南IP的账号在30秒内连续提交了47笔订单，全部使用同一张信用卡但不同收货地址。渗透试报运维人员起初以为是性测脚本刷单，直到发现这个账号的渗透试报登录凭证是从三天前一次看似正常的用户注册流程中获取的——注册时填写的手机号归属地是河南，但设备指纹显示为一台 rooted 的性测安卓模拟器。这就是渗透试报渗透性测试要抓的东西：不是防火墙日志里那些明晃晃的端口扫描，而是性测藏在正常业务流里的异常行为链。

很多人把渗透测试等同于用Nessus扫一遍漏洞，渗透试报或者拿sqlmap跑几个注入点。性测我见过一家做SaaS的渗透试报客户，每年花六位数买扫描服务，性测报告厚得像字典，渗透试报结果去年被一个简单的性测逻辑漏洞搞崩了——攻击者注册两个账号，利用邀请返现的渗透试报规则，用A账号邀请B账号，B账号消费后A拿返现，再把B账号的返现提现到A绑定的同一张银行卡。整个过程没有任何SQL注入、XSS或者越权访问，全是“合法”操作。渗透测试报告如果只列CVE编号和CVSS评分，这种业务逻辑漏洞根本进不了视野。

写报告的时候，我最怕看到“高危漏洞：3个，中危：7个”这种汇总表。数字好看，但开发团队拿到手不知道从哪改起。真正有用的写法是还原攻击路径。比如那次电商平台的案例，报告里应该这样写：攻击者通过批量注册接口的短信验证码回显漏洞获取手机号控制权（步骤1），利用优惠券叠加规则中的整数溢出使订单金额变为负数（步骤2），最后通过未校验归属地的提现接口将余额转出（步骤3）。每一步都配上HTTP请求的原始报文和响应片段，开发一看就明白该堵哪个环节。

测试环境跟生产环境的差异经常被忽略。有个金融客户，测试环境里所有接口都加了速率限制，报告结论是“无暴力破解风险”。上线后我们拿生产环境一测，登录接口的限流阈值是每分钟1000次——因为运维把配置文件的注释行也当成了生效参数。渗透测试报告里必须有一节专门写“环境差异导致的误判”，否则就是给客户埋雷。

关于工具，Burp Suite的Scanner模块确实能自动发现一些东西，但去年某次内部测试中，它把一个正常的OAuth回调参数标记为“开放重定向”。人工复核发现，那个参数虽然接受外部URL，但后端有白名单校验，只是校验逻辑写在了前端JavaScript里。工具不知道这个，它只看到参数值可控。报告里如果直接写“存在开放重定向漏洞”，开发改完前端校验，后端照样能被绕过。所以每个自动化发现都必须经过手动验证，验证过程要写进报告的“复现步骤”里。

最后说个细节：报告里的“修复建议”别写“对输入进行过滤”这种废话。要具体到代码层面。比如“在UserController.java的第87行，将String sql = "SELECT * FROM users WHERE id = " + id; 改为PreparedStatement预编译”。开发拿着报告就能改，不用再猜。渗透测试的终点不是发现漏洞，是让漏洞被真正修掉。报告写得再漂亮，开发看不懂或者懒得看，这活儿就白干了。