SQL注入如何绕过WAF防火墙拦截_通过编码转换与特殊字符混淆绕过

SQL注入如何绕过WAF防火墙拦截：编码转换与特殊字符混淆的艺术

URL编码和双重编码常失效，因WAF在解析阶段即完成多轮解码与规范化；真正有效的是利用WAF盲区如Unicode编码%u0027、十六进制0x27或数据库特有语法如MySQL条件注释/*!50700 SELECT*/。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

SQL注入绕过WAF时，URL编码和双重编码为什么常失效

很多朋友一提到绕过WAF，首先想到的就是URL编码，甚至双重编码。但现实往往很骨感：为什么%2527这样的把戏经常失灵？核心原因在于，现代WAF（无论是ModSecurity这样的开源方案，还是主流的云WAF）在请求解析的早期阶段，就已经完成了URL解码，并且通常会进行多轮规范化处理。简单来说，你发送的%2527（即%27的二次编码），WAF会层层解码，最终看到的还是那个赤裸裸的单引号'，该触发的规则一样会触发。

• 那么，什么编码才真正有效？关键在于找到WAF解析链条上的“盲区”。例如，某些WAF规则集不处理%u0027这种Unicode编码形式。但这里有个陷阱：数据库得认才行。MySQL就不吃%u0027这一套，需要换成数据库本身支持的格式。
• MySQL环境下，可以尝试0x27（十六进制字面量）来表示单引号字符，或者在特定上下文里直接用'。当然，前提是SQL语句的上下文允许这种十六进制字符串参与拼接。
• 如果是PostgreSQL，可以试试E'\x27'（带转义的十六进制字符串），部分WAF的规则可能没有覆盖到E''这种特殊的字符串语法。
• 所以，别再盲目套用%27→%2527的公式了。一个实用的测试方法是：构造像id=1%2527%2520OR%25201%253D1%2520--这样的payload，观察响应。如果还是被直接拦截，那就基本可以断定，目标WAF已经解码到了原始字符，这条路走不通。

用注释符和空格变形绕过关键词检测

WAF的另一大武器是基于正则表达式的关键词匹配，比如UNION SELECT、OR 1=1这类经典模式。好消息是，像MySQL、MariaDB这类数据库，对空白符和注释的容忍度极高，这给我们留下了操作空间。而且，不同数据库版本支持的注释语法也有细微差别，这恰恰是WAF规则难以全覆盖的地方。

• 用注释代替空格：这是经典手法。例如，把SELECT username FROM users写成SELECT/**/username/**/FROM/**/users。如果WAF的正则规则只是简单地锚定SELECT\s+FROM，那么这种写法就能成功溜过去。
• 利用MySQL条件注释：这是一个高级技巧。例如/*!50700 SELECT*/，其中的SQL语句只在MySQL版本号大于等于5.7.00时才会执行。这种数据库特有的语法，WAF的通用规则极少覆盖。
• 使用非常规空白符：除了常见的空格%20，还可以尝试%09（水平制表符Tab）、%0a（换行）、%0c（换页）。这些比单纯的+号要隐蔽得多。不过要注意一点：PHP的$_GET超全局变量默认会把+号转换成空格，但会保留%09的原义，这点差异在构造payload时需要留意。
• 注释符的选择：尽量避免使用-- （注意后面有个空格），可以改用#或块注释/*abc*/。部分WAF对行注释符#的过滤并不严格，尤其是当它出现在参数值末尾时。

利用函数别名与等价表达式替换敏感操作符

如果WAF采用的是黑名单机制，过滤了UNION、SELECT、AND等关键词，那么思路就要转向寻找“语义等价但字面不同”的写法。目标是让数据库引擎能正确执行，同时让WAF的规则识别不出来。

• 操作符替换：在MySQL中，逻辑AND完全可以用&&代替。对于AND 1这种布尔条件，甚至可以写成LIKE 'a'='a'这样的表达式来绕过检测。
• 拆分关键词：对于UNION SELECT这样的组合，可以在中间插入注释，变成UNION/*foo*/SELECT。或者，用括号改变语法树结构，写成UNION (SELECT ...)。
• 列数探测的隐蔽方法：探测列数时，不一定非要暴力使用ORDER BY 100。可以尝试嵌套SELECT子查询并用JOIN连接，例如：SELECT * FROM (SELECT 1)a JOIN (SELECT 2)b JOIN (SELECT 3)c...。这种复杂的嵌套语法，WAF规则很少会去覆盖其中的逗号分隔细节。
• 文件读取的绕过：当LOAD_FILE()函数被盯上时，可以尝试将文件路径转换为十六进制格式。例如：SELECT LOAD_FILE(0x2f6574632f706173737764)（对应/etc/passwd）。这样做既能绕过对常见路径字符串的检测，又避免了使用引号。

为什么堆叠注入（Stacked Queries）在多数场景下根本走不通

看到注入点有个分号;，很多人会兴奋地想到堆叠注入。但这里必须泼一盆冷水：WAF没有拦截分号，绝不代表后端应用程序能执行多条SQL语句。成败的关键，在于数据库驱动和应用程序接口（API）层是否允许执行多语句查询。

• 以经典的PHP为例，古老的mysql_query()函数根本就不支持多语句执行。较新的mysqli_multi_query()函数虽然支持，但出于安全考虑，绝大多数Web应用在编码时并不会启用这个选项。所以，即使WAF放行了id=1; DROP TABLE users--这样的payload，PHP代码调用mysqli_query($conn, $sql)时，也会直接返回一个“Commands out of sync”错误。
• 这个情况在其他语言中也类似。Python的pymysql库默认关闭多语句执行（multi=True）。Go语言的database/sql标准库同样不支持，除非进行显式配置。
• 堆叠注入唯一比较常见的可行场景，可能是在使用sqlmap这类自动化工具进行渗透测试时。例如使用sqlmap --batch -p id --dbms=mysql --technique=S参数，工具会先用布尔盲注或时间盲注确认注入存在性，然后再尝试堆叠注入。但即便如此，成功率也完全取决于后端代码的配置，并非WAF放行就能成功。
• 因此，不要把; SELECT当作万能钥匙。一个有用的判断方法是：仔细观察应用程序的错误信息，如果其中间出现了mysqli_num_rows()、pg_fetch_array()这类函数名，其实就暗示了底层使用的数据库驱动类型，从而可以推断堆叠注入的可能性。

总而言之，一次成功的SQL注入绕过，实际上是WAF规则粒度、数据库特定版本语法以及应用程序驱动配置这三者交集的产物。最容易被忽略的一点是：WAF可能“聪明”地放过了你的SELECT语句，但后端代码在拼接SQL之前，可能用一个intval()函数就把输入强制转成了整数，导致所有字符型payload在第一步就被截断了。所以，首要任务是确认：你的输入，真的进入SQL拼接环节了吗？