信息系统渗透测试

去年帮一家做跨境电商的信息系统朋友看系统，他们刚被薅了羊毛——优惠券接口没做频率限制，渗透有人写了个脚本半夜刷了三千多张。测试老板一直以为“我们又不是信息系统银行，谁会盯着我们”。渗透这话我听过太多次了。测试渗透测试要解决的信息系统第一件事，恰恰就是渗透打破这种“我不值得被攻击”的错觉。

说渗透测试，测试很多人脑子里浮现的信息系统是黑客敲几行代码，屏幕上一堆绿色字符滚动，渗透然后大喊“进去了”。测试实际完全不是信息系统这样。真实的渗透过程更像装修前验房，拿着清单一项项敲：门锁好不好使，测试窗户能不能从外面撬开，承重墙有没有被乱改。区别在于，攻击者不会按你的清单来。

先搞清楚“资产”到底有多少

我见过最离谱的一次，客户信誓旦旦说对外只有官网和API两个入口。结果扫了一遍C段，发现三台测试服务器挂着默认Tomcat页面，数据库端口3306直接对公网开放，密码是root/123456。运维两年前搭的临时环境，早忘了。

渗透测试的前期信息收集往往占掉整个项目一半以上时间。子域名、端口、指纹、泄露的源码、员工邮箱、甚至GitHub上的提交记录，都是入口。这一步没什么技术含量，但极其考验耐心。很多漏洞不是“攻”出来的，是“翻”出来的。

漏洞利用不是炫技，是验证

扫出漏洞报告谁都会用工具。难的是判断这个漏洞在当前环境下能不能真正造成影响。一个SQL注入点，如果数据库账号只有只读权限，且目标表里全是公开商品信息，那它的危害等级就得往下调。反过来，一个看似不起眼的SSRF，如果能打到内网Redis，那就可能直接接管整个集群。

我习惯在利用阶段手动复现一遍。工具报的“高危”有时候是误报，有时候是鸡肋。真正需要花时间的是把几个中低危漏洞串起来——比如通过信息泄露拿到后台路径，再用弱口令进后台，最后通过上传功能拿shell。这种组合拳才是真实攻击者的思路。

报告写给谁看，决定怎么写

渗透测试的交付物不是一堆截图。给开发看的报告要精确到请求包和修复代码建议，给管理层看的要讲清楚业务影响和修复优先级。我见过太多报告把“存在XSS”和“数据库可被拖库”并列在一起，老板看完根本不知道先修哪个。

有个细节：修复建议别只写“过滤特殊字符”。开发看到这种话会直接关掉文档。要写清楚在哪个文件、哪一行、用什么函数、过滤哪些字符、有没有现成的库可以用。越具体，修复率越高。

别忽略“人”这个环节

技术漏洞修得再快，一封钓鱼邮件就能让防线归零。我做过几次内部钓鱼演练，发了一封“年终奖发放通知”的邮件，附上一个需要登录的链接。三百人的公司，两小时内一百多人点了，四十多人填了账号密码。IT部门自己也有人中招。

渗透测试如果只测系统不测人，就像检查了所有门窗却把钥匙插在锁上。社会工程学不是选修课。

说到底，渗透测试的价值不在于找到多少个漏洞，而在于让团队意识到“被攻破”这件事有多具体。一个能复现的攻击路径，比一百页风险矩阵更有说服力。下次再有人跟你说“我们系统很简单没什么可黑的”，你可以回他一句：简单系统的攻击面往往更清晰，只是你没去看而已。