web渗透测试实战

去年冬天，渗试实我接了一个电商后台的透测渗透测试项目。客户拍着胸脯说系统用了WAF，渗试实代码审计也做过两轮。透测结果我打开登录页面，渗试实随手在用户名框里敲了个 ' or 透测1=1 --，页面直接跳进了管理员仪表盘。渗试实那一刻，透测客户脸上的渗试实表情比窗外零下十度的风还冷。

SQL注入这东西，透测二十年了还没死透。渗试实不是透测技术多高明，是渗试实开发习惯太顽固。很多人写查询直接用字符串拼接，透测觉得参数化查询"太麻烦"。渗试实我见过一个创业公司的API，每个接口都带 ?id= 参数，每个都能注入。问他们为什么不用预编译，回答是"框架默认这么写的"。框架默认不代表安全，默认配置经常是给开发省事，不是给你省心。

XSS比SQL注入更隐蔽。反射型XSS你发个链接骗人点，存储型XSS直接躺在数据库里等所有访客。我测过一个论坛，发帖内容过滤了 <script>，但没过滤 <img src=x onerror=alert(1)>。管理员每天看帖，每看一次就中一次招。后来我写了个payload，把管理员cookie偷出来，直接登录后台。整个过程不到二十分钟。

文件上传漏洞是另一条捷径。很多系统只检查前端JavaScript，后端完全信任传过来的文件。把 shell.php 改成 shell.jpg 传上去，再用路径穿越访问，服务器就归你了。我见过更离谱的——上传目录可以直接执行PHP，而且文件名就是原始文件名。传个 eval.php，里面写 <?php system($_GET['cmd']); ?>，然后浏览器访问 /uploads/eval.php?cmd=whoami，回显 www-data。那一刻你感觉自己像个魔术师，其实只是开发忘了关后门。

命令注入往往藏在"系统功能"里。有个客户做网络设备管理，后台有个ping工具。输入框里填 127.0.0.1; cat /etc/passwd，服务器乖乖把密码文件吐出来。他们用 system() 执行shell命令，没做任何转义。我问开发为什么不限制输入，他说"用户需要ping任意IP"。任意IP不等于任意命令，这两者之间差了一整个安全意识。

CSRF经常被忽略，因为利用起来需要诱导。但一旦成功，危害不比前面几个小。我做过一个实验：写个HTML页面，里面藏个自动提交的表单，指向某银行转账接口。受害者只要登录着网银，打开这个页面，钱就转走了。银行后来加了token，但很多中小系统还在裸奔。检查CSRF很简单——看关键操作有没有随机token，看token是否跟会话绑定。没有？那就有问题。

渗透测试不是拿着扫描器跑一遍就完事。工具能发现已知漏洞，但逻辑漏洞得靠人脑。我见过一个优惠券系统，满100减50，可以无限叠加。正常用户领一张，攻击者领一百张，下单时全用上，最后倒找钱。扫描器不会告诉你这是漏洞，因为从代码层面看，它"功能正常"。你得站在业务角度想：这个设计合理吗？能被人滥用吗？

最后说个真事。某次测试结束，我给客户列了修复清单。三个月后回访，发现他们只改了SQL注入，XSS和文件上传原封不动。问原因，答："开发排期太满，先修高危的。"可XSS和文件上传也是高危。安全不是打补丁，是改习惯。你修了一个注入点，但拼接字符串的写法还在，下一个接口照样中招。渗透测试的价值不在报告里那几十个漏洞，在于让团队意识到：攻击者永远在找最薄的那块木板，而那块木板往往是你觉得"不重要"的地方。