WAF实战：SQL注入绕过宝塔面板的攻防博弈

1. 从一次“被拒之门外”的测试说起

大家好，我是老张，一个在安全圈摸爬滚打了十来年的老兵。今天想和大家聊一个非常接地气，但又让很多新手朋友头疼的话题：如何与宝塔面板的WAF“过招”，特别是针对SQL注入的攻防博弈。你可能用过宝塔，它确实是个好东西，一键部署、可视化监控，让服务器管理变得像搭积木一样简单。但它的WAF（Web应用防火墙）有时候也挺“倔”，一个简单的1‘ and 1=1测试，可能就直接给你弹个拦截页面，让人瞬间懵圈。

这背后的场景，其实是我们安全测试或日常运维中经常遇到的。你想验证一下自己的网站有没有SQL注入漏洞，结果宝塔的防护规则先跳出来说“此路不通”。是网站真的固若金汤，还是我们的“敲门”方式不对？今天，我们就抛开那些复杂的理论，直接进入靶场实战。我会把自己在测试中踩过的坑、试出来的有效绕过方法，以及宝塔WAF可能的工作逻辑，掰开揉碎了讲给你听。目标很简单：不是教你去攻击别人的网站，而是让你彻底理解这套防护机制的“脾气”，从而更好地加固自己的阵地，或者在进行授权测试时，能更精准地发现问题所在。

我们这次的“战场”是一个经典的SQL注入靶场环境，但上面部署了宝塔面板的WAF防护。你会发现，很多教科书式的注入语句在这里直接失效。别急，这恰恰是乐趣的开始。攻防的本质就是博弈，是规则与绕过规则的智力游戏。通过一步步的试探、观察响应、调整Payload，我们不仅能学会绕过技巧，更能反向揣摩出WAF的过滤规则，这种“知其然更知其所以然”的体验，才是实战的精髓。

2. 初探战场：宝塔WAF的“第一道防线”

当我们把经典的1‘ or 1=1、1‘ and 1=1甚至1‘ || 1=1提交上去时，宝塔WAF几乎毫不犹豫地返回了拦截页面。这给我们传递了一个明确信号：它对一些常见的SQL逻辑运算符和关键字（如or, and, ||）建立了非常基础的“黑名单”匹配规则。 这种规则通常基于简单的字符串匹配或正则表达式，一旦发现请求参数中出现这些敏感词，就直接阻断请求。

这种防护思路直接有效，能拦住绝大部分自动化扫描工具和初级的攻击尝试。但它的弱点也在于“简单”。SQL语言是灵活的，同一种逻辑意图往往有多种表达方式。WAF的规则库不可能也无必要穷尽所有变形，这就给我们留下了迂回的空间。我的第一个突破口，是从一个看似不起眼的细节开始的：&&运算符。

在MySQL中，&&和and是等价的逻辑与运算符。当我尝试id=1 && 1=1时，发现请求居然通过了！但先别高兴太早，直接这么写，在HTTP请求中，&符号是参数分隔符，会被解析。所以我们需要对它进行URL编码。&编码后是%26，因此完整的Payload变成了：id=1 %26%26 1=1。这次，WAF放行了。