1. 为什么SQL注入与WAF的对抗一直没停过1.1 标题里的三层含义“SQL注入绕过WAF”这几个字表面看是一次攻击技术的总结实际上包含三个层面SQL注入本身、WAF的检测逻辑、以及两者之间的对抗关系。很多人一看到“绕过”两个字以为是一招鲜的payload集合但真正在实战中跑过一轮的人都知道绕过不是单点突破而是一个基于目标情况持续调整的过程。SQL注入之所以这么多年仍然排在OWASP风险清单的前列核心原因是它直接打击了数据层。业务系统只要有动态拼接SQL并且过滤不严就存在被注入的可能。WAF作为防护层拦截的是HTTP请求中的异常特征但它本质上是一个“门卫”看到的只是请求正文看不到数据库内部执行情况。正是因为WAF与数据库之间存在认知差绕过才成为可能。你需要理解三层请求是怎么被解析的、WAF用哪些规则匹配、后端数据库又是怎么执行这条指令的。这三层只要有任何一层能利用差异绕过路径就可能成立。1.2 什么人需要真正理解这个话题这个话题不只是红队人员需要蓝队人员、安全研发、DevOps工程师同样值得研究。红队理解绕过是为了在授权测试中发现防护缺口蓝队理解绕过是为了反推检测规则哪里失效进而完善WAF配置研发理解绕过是为了在设计查询语句时就从源头避免拼接风险。我见过很多WAF规则写得非常长的团队几千条规则堆上去结果绕过测试时依然被一个简单的注释符思路击穿。问题就出在规则只是在已有攻击样本上打补丁没有去理解注入的本质结构。本文想把常见的绕过思路和背后的原理讲清楚顺便聊聊防御侧怎么针对这些思路做闭环而不是简单堆规则。2. WAF到底在拦什么先看懂检测机制2.1 正则与规则库的经典思路传统WAF最核心的检测手段是正则匹配。它会从HTTP请求的URL、请求头、POST参数、Cookie等位置提取数据然后与内置规则库做匹配。规则库里通常会包含很多“危险信号”比如常见的注入关键字、闭合符号、函数调用、系统命令等。这类正则规则的一个显著特点是命中率依赖规则覆盖面但规则越多误报越高。于是不少WAF会做分级策略比如普通请求只查高危特征登录接口额外查SQL特征文件上传接口查上传特征。分级确实能降低误报但也给攻击者提供了区分WAF策略边界的机会。比如某个接口不在重点检测范围内那么它的防护强度明显低于其他接口测试者就可能在看似无害的接口上找到突破口。同时正则匹配还有天然缺陷它对语义不够敏感。一个字符串中出现“select”并不代表它真的在拼SQL反过来经过函数拆分、编码转换后的恶意语句正则可能根本认不出来。这就是为什么WAF需要不断更新规则也是为什么纯规则型WAF在面对变形攻击时经常显得“笨拙”。2.2 语义分析与行为检测的进化近几年比较成熟的WAF产品在正则之外增加了语义分析引擎。它会把SQL语句片段尝试解析为AST语法树再去判断是否存在注入结构。比如一个参数值被拼接到SELECT语句中如果闭合后形成了新的语法节点就可能被标记为异常。语义分析的好处是能应对部分字符变形比如去掉空格、替换关键字大小写、加上注释符解析后仍然能还原出真实的执行结构。但语义分析也有代价它需要模拟后端数据库的语法规则而且很难完全模拟所有数据库方言。面对MySQL、SQL Server、Oracle、PostgreSQL的差异分析引擎就得维护多套解析逻辑。行为检测则是从请求频率、来源IP、目标接口的访问规律上做判断。比如某个IP在短时间内对同一个接口发起了大量包含特殊字符的请求即便单条请求没有命中规则整体行为也会触发告警。这类检测对攻击扫描有帮助但攻击者一旦放慢速度、分散节点行为检测的效果也会明显下降。2.3 场景还原一次注入请求如何在WAF里走一圈我们假设目标是一个登录接口参数为username和password。攻击者在username提交了admin or 11这条请求会先到WAF而不是直接到后端。WAF先检查URL路径确认是/login接口然后提取POST参数值进入检测流程。规则引擎会把字符串与规则库做匹配发现单引号后面跟着or这通常会被标记为高风险。于是请求被拦截后端连收到数据的资格都没有。但如果提交的是admin/*!50000or*/11结果可能完全不同。注意/*!50000or*/是MySQL内联注释的一种写法在MySQL版本大于5.0时会解析为关键字or而部分WAF规则库没有覆盖这种写法可能只看到注释符号就没触发拦截。这就是一个典型的绕过路径利用WAF的语法认知不足。这个例子说明WAF的每一次检测都是一次“读取—解码—匹配”的过程任何一步如果和目标环境的处理方式不一致都可能打开缺口。3. 常见的SQL注入绕过WAF手法拆解3.1 关键字与函数替换盯上正则的命门正则规则库依赖“关键字是否出现”来判断风险于是关键字替换成为最基础也最有效的一类绕过思路。以or为例它在SQL注入中常被用来构造恒真条件比如 or 11 --。但直接出现or很容易被拦截于是测试者会尝试向量替换在MySQL中||可以作为逻辑或使用于是可以写成||11 --。如果WAF只盯着or就可能漏掉||。函数替换也很常见。比如检测到sleep()就换用benchmark()或者pg_sleep()检测到substring()就换用mid()、substr()。关键在于WAF规则不一定把这些函数全部覆盖而且不同数据库的内置函数不一样规则库维护方很难把所有变体都收集完整。这还只是静态替换。更高级的做法是给关键字或函数名中间“插入”注释符比如sel/**/ect。对后端SQL解析器来说注释符会在词法分析时被忽略关键字最终依然有效但在正则匹配时字符串不再是完整的select规则自然就失配了。这里需要注意插入注释符的位置和注释符号类型取决于目标数据库是否支持以及是否在允许的字符上下文中。3.2 注释符与空白变体最容易被忽视的缝隙很多初学者不理解注释符在绕过中的真正价值总觉得它只是拼接时“封口”用的。实际上注释符能承担三重职责截断后续语句、代替空白分隔符、插入关键字内部打乱规则匹配。第一重职责最常见用--或#把后面的拼接部分注释掉避免语法错误。第二重职责经常被忽略比如select(a)from(b)这种写法括号在部分数据库中可以作为分隔符使得语句不需要空格也能解析。第三重职责就是前面说的/**/插到关键字中间。空白字符的变化也值得一提。URL中常见的%20是空格但很多WAF会对空白字符做归一化把%09、%0a、%0d、%0b等同为空格处理。但后端数据库和Web容器的解码方式可能存在差异比如某些环境会把%0a解成换行而SQL解析器允许换行作为空白。这样一来请求里用换行替代空格就可能绕过依赖空格分隔的正则规则。不过这类手法的上手难度不高防护方也容易通过“把所有空白字符统一归一化”来封堵。真正难防的是非线性组合比如把空白字符、注释符、大小写混合使用单看每一个片段都很正常合在一起却能拼出一条完整语句。3.3 编码与双重编码让规则认不出货编码绕过的核心思路是WAF解码后的内容和后端最终解码后的内容不一致。URL编码是最常见的比如单引号编码为%27空格编码为%20如果WAF在读请求时没有先解码那么规则匹配到的是编码后的字符串自然无法识别。更隐蔽的是双重编码。假设WAF只解码一次后端容器可能因为配置问题会解码两次。第一次解码后是%2527第二次解码后才是%27对应的单引号。如果WAF的解码次数小于后端就可以用双重编码绕过。这类问题多见于Nginx反代和Tomcat等中间件配合时不同组件的解码策略不同。Unicode编码也偶尔用得上比如把部分字符替换成Unicode全角形式但后端数据库或中间件做编码转换的时候可能映射回ASCII字符。不过这种情况受字符集配置影响很大成功率不高而且现在很多WAF会做多重解码自动把常见的URL、Unicode、十六进制都还原一遍。编码绕过的本质不是多试几次编码而是要先摸清“WAF解码到第几层”和“后端解码到第几层”。我一般会在授权测试中先做一个编码层级探测用同一个payload分别做单次、双重、三重编码提交看哪些组合能产生不同的检测结果这比盲目尝试高效得多。3.4 HTTP参数污染利用WAF与后端的认知差HTTP参数污染HPP不算新招但它是绕过WAF的一条稳定路径。原理是同一个参数名提交多次比如?id1id2WAF可能只检查第一个值或者最后一个值而后端框架取值的规则可能完全相反甚至会把所有值拼接在一起。比如 PHP 的某些版本遇到同名参数会取最后一个而 ASP.NET 的解释器会把多个值拼接成逗号分隔的字符串或者只取第一个。如果WAF和后端取参规则不一致攻击者可以把恶意的注入片段放在WAF不检查的那个参数值里后端却把它解析进SQL语句。HPP在处理JSON请求体时也常见。有些WAF只解析表单格式对JSON内容只做简单关键词检查但后端框架会完全解析JSON结构。测试者构造一个嵌套JSON把注入语句藏到深层字段里WAF可能根本没展开深层内容。防护HPP比较有效的方式是在网关层统一解析参数来源明确同名参数的处理策略并强制WAF与后端使用同一套参数获取逻辑切断认知差。3.5 数据库方言差异同一个绕过不一定通用很多绕过思路是数据库相关的脱离目标数据库类型去谈绕过意义不大。以注释符为例MySQL 支持#和--SQL Server 支持--也支持/* */Oracle 只支持--和/* */PostgreSQL 基本类似。如果你拿#去测Oracle后端会直接报语法错误WAF根本没拦但你也注不进去。函数名差异更明显。MySQL 有sleep()、benchmark()、updatexml()、extractvalue()SQL Server 的常用函数是waitfor delay和stuff()Oracle 的注入常配合xmltype、dbms_pipe等特性。一套绕过payload能不能生效第一步就得先判断数据库类型。版本差异也会影响绕过策略。MySQL 5.x 支持内联注释/*!50000select*/在低版本环境下解析方式可能不同MySQL 8.0 对部分语法做了调整以前常用的某些写法就失效了。所以每次测试之前我会先通过报错返回或响应差异确认数据库版本再决定用哪一套绕过方法组合。4. 从绕过手法反向看检测盲区与防御建议4.1 WAF规则为什么总漏从上一章的绕过手法能很清楚地看到WAF规则漏拦截的根本原因不是数量不够而是对“可执行语义”的覆盖不到位。规则库本质上是一个有限集合而SQL语法和HTTP编码的组合是无限的。一旦攻击者把关键字拆开、把空白替换、把编码层级错开规则库就出现了大量盲区。另一个漏拦截原因是规则冲突。很多团队为了减少误报会把某些危险关键字在特定接口放行。比如允许普通用户在“搜索”页面提交%和_这两个模糊查询通配符但如果同一个正则也被用在另一个参数上攻击者就能利用放行逻辑钻空子。还有一类漏洞是由WAF自身的性能保护机制引发的。当请求体过大、参数过多或检测超时时WAF可能干脆跳过检测直接放行。攻击者可以用大体积上传、海量参数把WAF“拖垮”然后在某个不起眼的角落里藏真正的注入语句。这是设计上最难权衡的点为了提高可用性而牺牲安全性最终都会以另一种方式补回来。4.2 真正靠谱的防御顺序对于SQL注入防护WAF只是最后一道过滤网不是第一防线。正确顺序应该是参数化查询优先输入校验次之WAF兜底。参数化查询的意思是SQL语句的结构和参数值分开传递数据库先编译SQL模板再把参数值当作纯数据绑定进去。这种情况下用户输入永远不可能成为SQL语法的一部分无论输入什么内容都不会改变语句结构。这是从根上解决SQL注入的唯一方法。如果实在无法使用参数化查询比如要拼接动态表名那就要做严格的白名单校验。表名、排序字段这种结构型输入尽量用枚举值控制而不是让用户直接输入字符串拼进SQL。WAF则用来兜底拦截那些明显恶意的请求同时记录攻击行为防止漏网之鱼直接命中后端。防御不是选一个方案而是让每一层各司其职。参数化解决大部分问题白名单解决结构拼接问题WAF解决扫描和试探行为这样即便WAF被绕过也不会对数据造成实际损害。4.3 与开发配合的几个落地细节在推动防御落地的过程中我发现安全团队总觉得开发同学不配合其实很多时候是没有把需求讲清楚。开发真正关心的是改动会不会影响现有功能需要排期多久有没有兼容老数据的风险。安全团队能给开发提供的最有价值的东西是清晰的修复示例而不是一堆漏洞报告。比如对于历史遗留的拼接SQL直接给出一个改写成参数化查询的对比diff开发照着迁就很快对于动态表名这类难改的点给出白名单枚举的参考实现开发也容易接受。同时在测试阶段要把绕过的思路转化为自动化回归用例。把常见的绕过变体比如关键字内插注释、编码层变化、不同空白字符组合整理成用例集每次WAF规则更新后自动跑一遍确保没有修一个洞又开一个洞。这比单纯依赖人工反复测试更稳定也更符合实际工程节奏。5. 实战经验记录一次授权测试中的绕过思路复盘5.1 初步探测与信息收集有一次在授权范围内测试一个内部系统的列表接口参数是一个数字ID形如/list?id1001。我第一轮提交了?id1001接口返回了500错误并且错误信息里带出了数据库类型和部分SQL片段。这个信息非常关键确认是MySQL版本在5.x。随后我尝试?id1001 and 11和?id1001 and 12对比响应长度确认存在闭合注入点。但直接测试union select时WAF返回了拦截页面。这里就能判断WAF是纯规则型因为我用了空格和标准关键字立刻被识别。接下来做的第一件事不是急于换payload而是先探测WAF的解码层和过滤范围。我提交了%27、%2527、%252527三组分别观察是否触发拦截。最终发现WAF只做了一次URL解码而中间层会二次解码于是双重编码路径就成为了后续重点。5.2 选定绕过路径的依据考虑到是MySQL且WAF对标准关键字敏感我选择了注释符内插作为首条路径。把union select改写成union/**/select之后提交WAF没有拦截后端返回了正常的查询结果说明注释符构造对它有效。接着我把空格替换成/**/或者%0a逐步测试各关键位置的替换效果。在确认WAF对注释符不敏感后我用同样的思路构造了union/**/select/**/1,2,3成功拿到了字段数。这里有一个值得说的细节我没有立刻去尝试information_schema这类重型查询而是先用简单数字确认注入结构因为此时如果把WAF激活后面所有操作都会更难开展。测试动作要从小到大逐步加码每一步都观察是否触发拦截一旦触发就回退到上一步改用其他变体。5.3 绕过后的收尾与修复建议拿到数据后我没有直接跑大量数据而是按授权范围最小化收集并在报告里详细记录了绕过路径。修复建议上我明确告诉开发侧这个接口应该改用参数化查询不能只依赖WAF规则。因为绕过的根本原因不是WAF没有拦截而是WAF对注释符内插和双重编码的组合认知不足。即使把/**/加入规则攻击者还可以用换行符、括号分隔、等价函数等继续换变体。所以真正的修复必须回到代码层让输入不再参与SQL结构拼装。复盘这条路径时我最大的感受是绕过成功往往不是靠一个奇技淫巧而是靠完整的信息收集和逐步试探。很多人一上来就扔一堆payloadWAF拦了就换另一个最后撞运气这种方式的成功率很低。6. 常见问题与排查技巧实录6.1 为什么改完WAF规则还是被绕这个问题出现的频率非常高。一个常见原因是只针对绕过样本做了精确匹配没有抽象出通用结构。比如发现union/**/select能绕过就在规则库里加一条专门匹配union/**/select的内容但攻击者换成union%0aselect或union/*!50000select*/这条规则就失效了。更好的做法是抽象出语义层规则检测参数值中是否存在union和select且两者之间被任意空白/注释/括号分隔。也就是说把“关键字A后面跟着关键字B中间可接受若干特定元素”这种结构抽象出来才能覆盖更多变体。另一个容易被忽略的原因是WAF和后端解析资源的差异。比如WAF默认不检测JSON的嵌套字段或者对multipart格式解析不完整那么无论规则怎么改只要解析器覆盖不到绕过路径就一直存在。排查时要把WAF的解析器行为和后端容器的解析器行为逐项对齐。6.2 哪些绕过手法现在不好使了以前很流行的大小写混写现在大多数WAF都会先做lower转换这招基本失效。单纯的URL编码也很容易被解码后检测。关键字中间插入单行注释符/**/在主流WAF里命中率也大大提升不过换成内联版本注释/*!50000...*/或换行符变体仍然有存活空间。等价函数替换能否继续使用取决于目标WAF的函数库覆盖程度。比如有些WAF会主动检测benchmark()、pg_sleep()等危险函数但漏掉ST_GeomFromText()、GTID_SUBSET()这类冷门函数。这类函数的影响面比较窄但偶尔会有惊喜。HPP 和编码层级错配如今依然有效因为这类问题源自架构差异WAF厂商很难通过自身更新完全修复。所以排查时要重点看网关和WAF是不是同源解析如果各层采用不同的参数取值规则HPP就是一条长期存在的绕行通道。6.3 给红队新手的三个提醒第一别一上来就开大流量扫描。扫描器的高频率请求会让WAF的行为检测先告警目标一旦将你的源IP加入黑名单后续手工测试也全部白费。先用手工测试确认注入点再考虑自动化扩展。第二payload不是越多越好而是越匹配越好。先确认数据库类型、版本、WAF解码层级、过滤强度再有针对性地构造两到三套变体链。盲目跑一堆通用payload只会把WAF的告警噪声拉高。第三绕过WAF是授权测试中的技术验证不是目的。拿到数据之后要尽快收敛在测试范围内的最小数据集上做确认然后把修复方案和时间线写清楚。只破不防没有意义真正价值在于帮目标把风险点修掉。7. 最后再分享一点我的个人体会做了这么多年安全攻防我越来越觉得“sql注入绕waf总结”这类话题最大的价值不在于那几条payload而在于理解对抗背后的思维路径。WAF只是一个执行者它的行为取决于规则、解析器、性能保护策略和目标环境的组合。绕过它本质上就是寻找这个组合中的认知偏差。我自己的习惯是每测完一个目标都会把WAF的拦截日志和绕过记录放到一起复盘看它到底拦了什么、漏了什么、为什么漏。这个动作比多学几个新变体更有用因为下一次遇到的目标可能数据库不同、中间件不同但对抗思路是可以复用的。另外防守方也不用把绕过技巧当成洪水猛兽。红队的绕过路径恰恰是蓝队最好的自查清单。每一次完善的绕过测试都在帮防御体系打补丁。关键是要形成闭环发现问题、修复验证、回归测试、沉淀规则。只要这个闭环跑起来不管是WAF规则还是代码层的防护都会越来越扎实。如果你也正在做这类攻防测试建议先把基础的信息收集和解码探测做扎实再考虑各种高级变体。基础越稳绕过的路越宽。