渗透测试报告案例：一次绕过WAF拿下管理后台的渗透真实记录

客户是一家做跨境支付的创业公司，资产不多，测试一个官网加一个用户后台。报告目标明确：拿到后台管理员权限，案例证明他们最担心的渗透数据泄露路径真实存在。测试周期三天，测试我第二天就进去了——但过程比想象中曲折。报告

官网是案例个标准PHP站，nginx做反代，渗透前端套了Cloudflare。测试常规扫目录没发现什么，报告后台入口藏在`/admin_v2/login.php`，案例文件名带版本号，渗透明显是测试改过的。尝试弱口令，报告admin/admin直接拒绝，连续三次后IP被ban——有防护，而且不是简单的登录失败锁定，是WAF层面的临时封禁。

换思路。抓包看登录请求，发现密码字段是明文传输，但有个隐藏参数`debug=0`。手动改成`debug=1`，响应里多出一行注释：``。好家伙，直接暴露了查询语句。这属于典型的信息泄露，但攻击面还不够。

试了试SQL注入，WAF拦得死死的，单引号、union、sleep全被过滤，返回403。常规payload没戏。我盯着那个`debug`参数看了几分钟——既然能回显SQL，那能不能让它回显别的？改`debug=2`，没反应；`debug=3`，页面直接空白。再试`debug[]=1`，PHP报错信息弹出来了：Array to string conversion。这下确认了，参数值会被拼进某个字符串处理函数里。

顺着这个思路，我尝试用参数污染绕过WAF的检测规则。具体做法是同时提交两个同名参数：`debug=0&debug=1' AND (SELECT 1 FROM (SELECT SLEEP(5))a)-- -`。WAF只检查了第一个`debug`的值，第二个直接透传到了后端。延迟5秒，页面才响应——注入成功。这个绕过方式不算高明，但对付规则匹配型的WAF往往有效，因为很多WAF只解析第一个同名参数，而PHP默认取最后一个。

接下来就是常规操作了。用报错注入提取数据，`extractvalue`函数虽然被过滤，但`floor(rand(0)*2)`的group by报错还能用。费了点时间拿到管理员密码的MD5，彩虹表一查，明文是`P@ssw0rd2024`——典型的强密码策略下的人为妥协。

登录后台，发现功能比想象中简陋。用户列表、交易记录、提现审核，三个模块。真正让我意外的是，交易记录导出功能存在存储型XSS，导出的CSV文件里直接塞了`