宝塔面板WAF下SQL注入绕过实战：从联合查询到布尔盲注的完整思路

宝塔面板WAF下SQL注入绕过实战：从联合查询到布尔盲注的完整思路

最近在渗透测试项目中，我遇到一个挺有意思的挑战。目标站点部署了宝塔面板自带的WAF防护，常规的SQL注入手法几乎全部失效。联合查询被精准拦截，注释符也成了摆设，那种感觉就像面对一扇看似普通的门，手里却找不到能插进去的钥匙。很多安全研究员可能都遇到过类似场景，在WAF规则日益智能化的今天，传统的“三板斧”越来越不灵光。这篇文章，我想和你分享的，就是在这种高压防护下，如何转换思路，从看似无路可走的联合查询失败，一步步转向布尔盲注，并最终成功绕过的完整实战心路历程。这不仅仅是技巧的堆砌，更是一种在受限环境下进行逻辑推理和创造性测试的思维训练。

1. 环境侦察与注入点确认

在开始任何绕过尝试之前，扎实的基础侦察是必不可少的。这能帮你理解你面对的是什么，以及规则可能在哪里留下了缝隙。

1.1 初探与基础指纹识别

面对一个可能存在注入的端点，比如 ?id=11，我的第一步永远是观察。正常的页面返回了什么内容？页面结构、数据展示方式、有无错误信息回显，这些都是宝贵的信息。宝塔WAF的一个特点是，它通常不会完全屏蔽错误，而是倾向于拦截“危险”的请求并返回一个统一的拦截页面（比如403或特定的WAF拦截提示）。因此，观察页面内容“消失”还是“变化”，比看是否报错更重要。

接下来就是经典的注入点探测。我尝试了最基本的单引号 '：

?id=11'

页面内容突然不见了，或者跳转到了一个空白/错误页。这是一个强烈的信号，说明输入被以某种方式处理了。为了确认这是注入点而非单纯的过滤，我尝试闭合它：

?id=11''

当页面内容神奇地恢复时，我心里基本有数了：这里存在一个基于单引号字符的注入漏洞。WAF可能检测到了第一个单引号，触发了某种过滤或拦截机制，但第二个单引号使其闭合，语句又变得“合法”了。这一步至关重要，它确认了漏洞的存在性，是后续所有绕过尝试的基石。

注意：有些配置严格的WAF可能会直接阻断包含单引号的请求。如果遇到这种情况，可以尝试双引号、括号或其他闭合方式，或者考虑使用HTTP参数污染（HPP）等技巧在参数中引入分隔。

1.2 注释符的攻防博弈

在SQL注入中，注释符（如 --+, #, /* */）的作用是注释掉原始查询中后续的代码，使我们注入的语句能干净地执行。然而，宝塔WAF对这类符号的检测非常敏感。

我依次测试了常见注释符：

• -- -：通常被拦截。
• #（URL编码为%23）：同样被拦截或无效。
• /* */（内联注释）：也被识别并阻断。

这堵墙似乎密不透风。但WAF规则往往是基于正则表达式或关键字列表，总有覆盖不全的角落。这时我想起了空字节截断技巧。在某些特定环境（尤其是老旧或配置不当的PHP版本与特定数据库交互时），;%00（分号加空字节）能起到终止语句或引发解析异常的效果，有时可以绕过对注释符的依赖。

尝试：

?id=11' ;%00

页面返回正常了！这意味着我们成功地在注入点后“结束”了查询，无需依赖传统注释符。这是一个关键的突破口，它为我们后续注入载荷的构造扫清了一个主要障碍。当然，%00的有效性高度依赖于后端语言和数据库的解析特性，并非万能钥匙。

2. 联合查询的突围与受挫

有了可控的注入点和绕过注释符的方法，很自然地，我会优先尝试信息获取效率最高的联合查询（Union Select）。

2.1 字段数探测：Order By的幸存

联合查询的前提是知道前后查询的字段数必须一致。因此，ORDER BY 子句是标准的第一步。令人稍感意外的是，在这个案例中，ORDER BY 并没有被宝塔WAF拦截：

?id=11' order by 10 ;%00
?id=11' order by 5 ;%00

通过二分法，我很快确定了字段数量。这个过程顺利得让人心生希望，仿佛胜利在望。

2.2 Union Select的铜墙铁壁

然而，当我满怀信