黑名单过滤在SQL注入防护中本质失效，因其仅做字符串匹配，而数据库执行语法树；如UnIoN/*/SeLeCt、%75nion等变形可绕过大小写、注释、编码检测，且内联注释/!50000UNION*/等特性使WAF与数据库解析产生语义鸿沟。

简单的关键字黑名单在SQL注入防护中基本无效——不是“效果差”，而是从设计原理上就注定失效。

黑名单匹配 vs 数据库语法解析，根本不在一个维度

过滤器看到的是字符串，数据库执行的是语法树。比如 union select 被拦了，但 UnIoN/**/SeLeCt 在字符串层面不匹配黑名单项，而 MySQL 解析时会忽略注释、不区分大小写，最终仍执行为标准 UNION 查询。

常见错误现象：页面返回 403 或空白，但换一种大小写或加个 /**/ 就成功执行；或者 id=1%20UNION%20SELECT 被放行，因为 URL 解码发生在过滤之后，而过滤器只扫描原始请求体。

• 过滤时机错位：WAF 或中间件常在 request body 解析前做正则匹配，但数据库接收的是经 PHP/Java 等后端处理后的最终字符串
• 语义鸿沟：sel%65ct（%65 是 e 的 URL 编码）对人是“select”，对简单正则却是“sel%65ct”，对数据库却是 select
• 无状态匹配：一次替换（如把 union 换成空）会导致 ununionion → union，双写绕过直接生效

空格、注释、分隔符的多样性让“切词”不可靠

SQL 解析器允许大量合法空白和结构替代符，而黑名单很难覆盖所有组合。一旦空格被过滤，攻击者立刻转向 %09、%0a、/**/、( )、反引号等十数种替代方式。

使用场景：CTF 题目或老旧 CMS 常见 preg_replace('/union|select/i', '', $input)，结果 id=1'/**/UNION/**/SELECT/**/1,2,3-- 全部绕过。

• /**/ 不仅能替代空格，还能跨关键字拆分：SEL/**/ECT
• %09（Tab）和 %A0（NBSP）在部分 WAF 规则中未被列入空白字符白名单
• 括号可包裹整个子句：UNION(SELECT(1),database(),user())，绕过“关键字+空格”检测逻辑

内联注释和版本特性成为绕过“高级黑名单”的常规手段

MySQL 的 /*!50000UNION*/ 是典型例子：它对 MySQL 是可执行代码，对 WAF 却是“以 /* 开头的注释”，多数规则直接跳过不扫描。

性能影响：启用深度语法解析（如 SQL 解析引擎）会显著增加延迟，生产环境极少部署；而纯字符串匹配又无法识别 /*!*/ 这类上下文敏感结构。

• /*!50000 中的数字表示最低兼容版本，MySQL 会执行，其他数据库忽略
• PostgreSQL 支持 /*+ */ 提示语法，也可用于混淆
• Oracle 的 /**/ 和 -- 行注释行为与 MySQL 不同，绕过策略需按数据库类型调整

真正难防的不是单点绕过，而是组合变异与上下文逃逸

现代绕过往往不是“换一个词”，而是多层变形叠加：URL 编码 + 大小写 + 注释拆分 + 内联注释 + 宽字节拼接。例如 %75nion%2f%2a%2aselect（即 union/**/select 的双重编码），在经过两次解码后才还原为有效 payload。

容易被忽略的地方：很多防御方案只测了单层绕过，却没考虑后端是否做多次 decode（如 Nginx 解一次、PHP urldecode() 又解一次），导致“看似已过滤”的字符串实际在数据库前完成了还原。