SQL注入至今仍是Web应用面临的最致命威胁之一，很多运维人员以为部署了WAF就能高枕无忧，但实际情况是大量绕过手法依然能穿透默认策略。问题不在于WAF本身没用，而在于绝大多数WAF上线后只保持了出厂配置，规则阈值、解码层级、参数白名单、响应拦截逻辑都没有针对业务做过调整。攻击者只要对Payload做几次编码变换、利用注释符打断关键字、或者把恶意语句塞进JSON和XML结构里，默认规则就会失效。要真正提升SQL注入防护能力，必须从解析深度、规则组合、上下文感知和持续运营四个维度对WAF做系统性优化。

先调整解码与规范化策略，堵住编码绕过的口子

WAF检测SQL注入的第一个关键环节是内容解码。攻击者常用的手法是对Payload进行URL编码、双重URL编码、Unicode编码、十六进制编码甚至混合编码。如果WAF只做一次URL解码就进入规则匹配，那么类似%2527这种双重编码后的单引号就会直接穿透。正确的做法是在WAF配置中开启递归解码，并设置合理的解码深度上限。一般建议递归解码层数设置为3到5层，既能覆盖绝大多数编码绕过场景，又不会因为过度解码导致性能急剧下降。同时要开启对Unicode编码、HTML实体编码和Base64编码的识别能力，尤其是当业务接口明确接收Base64或JSON格式数据时，WAF必须对解码后的内容重新执行SQL注入规则检测。

另一个容易被忽略的规范化问题是字符集处理。如果WAF按照UTF-8解析请求体，但后端数据库或应用服务器使用GBK或GB2312处理输入，攻击者就可以利用宽字节注入构造出反斜杠逃逸场景。在WAF中明确指定与后端一致的字符集，并开启宽字节检测规则，能有效阻断这类利用字符集差异发起的攻击。对于无法统一字符集的旧系统，至少要在WAF层面对0x5c和0x27等关键字节的组合模式做重点监控。

优化SQL注入核心规则，减少误报同时提高检出率

默认规则库通常追求覆盖面，但缺乏对业务语境的判断，导致大量正常请求被误拦，运维为了减少投诉只能把规则改成观察模式或者直接关闭，防护形同虚设。更合理的做法是基于业务接口的实际参数特征做规则裁剪。先梳理出哪些接口会接收自由文本输入，哪些接口只接收数字ID、枚举值或固定格式字符串。对于只接收数字的参数，可以配置严格的类型白名单，直接拒绝任何包含字母和特殊符号的请求，这比任何SQL注入规则都更可靠。对于必须接收自由文本的搜索框、评论框，再启用完整的SQL注入检测规则，并针对性地调高敏感规则权重。

在规则组合层面，单条规则匹配单一关键字很容易被注释符、空白符和内联注释绕过。比如攻击者把union select写成union//select或者union%0aselect，如果WAF规则只匹配连续字符串就会漏报。优化方法是在WAF中启用多规则关联检测，将关键字识别、语法结构识别和异常字符密度检测组合起来。例如同时满足“包含union关键字”“包含select关键字”“两者之间出现注释符或空白符”“参数值长度超过正常范围”这四个条件时再触发拦截。这种组合判断能显著降低误报，同时让绕过难度大幅提升。

对于已经出现过的攻击样本，要充分利用WAF的自定义规则功能。把攻击日志中捕获到的真实Payload提取特征，转化成精确匹配规则或正则规则。比如发现攻击者使用特定编码顺序绕过，就把该编码序列本身作为特征写入规则。这种基于真实对抗经验沉淀下来的规则，比通用规则库更贴合自身业务面临的威胁。

开启上下文感知检测，覆盖JSON、XML和分块传输场景

现代Web应用大量使用JSON和XML作为数据交换格式，SQL注入Payload经常被嵌入到这些结构化数据中。很多WAF默认只对表单参数和URL查询字符串做检测，对JSON和XML的解析深度不够，导致攻击者把恶意语句放在嵌套的JSON字段里就能绕过。优化配置时必须在WAF中开启对JSON和XML的深度解析，并确保解析后的每个字段值都经过SQL注入规则检测。对于JSON，要特别注意嵌套对象和数组中的字符串值；对于XML，要覆盖元素内容、属性值和CDATA区块。

分块传输编码是另一个高频绕过通道。攻击者把HTTP请求体拆分成多个小块发送，每块只包含Payload的一部分，WAF如果只对单个分块做检测就看不到完整的攻击语句。在WAF配置中必须开启分块传输重组功能，将全部分块内容合并后再进行安全检测。同时要限制单个分块的大小和总请求体大小，防止攻击者利用超长分块消耗WAF资源造成拒绝服务。

HTTP参数污染也需要在配置层面加以防范。当请求中出现多个同名参数时，不同后端技术栈的处理方式不同，有的取第一个值，有的取最后一个值，有的拼接所有值。攻击者可以利用这种差异，在第一个参数中放正常值，在后面的参数中放恶意值，如果WAF只检测第一个参数就会漏报。优化配置时应让WAF对所有同名参数值都执行检测，并且对参数值拼接后的完整内容再做一次检测，确保无论后端采用哪种取值逻辑都能覆盖到。

配置响应检测与信息泄露阻断，降低攻击收益

SQL注入防护不能只盯着请求方向，响应方向的检测同样重要。当攻击者成功执行注入后，数据库错误信息、表结构信息、敏感数据往往会直接出现在响应页面中。WAF应开启响应内容检测，对包含数据库错误特征、SQL语法错误提示、敏感字段名和异常数据模式的响应进行拦截或脱敏。常见的数据库错误特征包括MySQL的“You have an error in your SQL syntax”、SQL Server的“Unclosed quotation mark”、Oracle的“ORA-”错误码等。把这些特征写入WAF响应规则，能在攻击者探测阶段就切断信息反馈，大幅增加注入利用的难度。

同时要在WAF中配置敏感信息泄露防护规则，对响应中的身份证号、手机号、银行卡号、密码哈希等敏感数据模式进行识别。即使攻击者通过盲注方式逐字节提取数据，只要响应中出现了符合敏感数据格式的内容，WAF就能触发告警或阻断。这种响应侧防护与请求侧检测形成互补，能显著降低注入攻击的实际危害。

建立规则调优与日志分析闭环，让防护持续有效

WAF上线后的持续运营比初始配置更重要。SQL注入攻击手法在不断演变，业务接口也在持续变化，如果规则长期不更新不调整，防护能力会持续衰减。建议建立每周一次的WAF日志复盘机制，重点分析被拦截的SQL注入请求和疑似漏报的异常请求。对于被拦截的请求，要确认拦截是否准确，是否存在误伤正常业务的情况。对于返回200状态码但请求参数中包含可疑SQL片段的请求，要人工判断是否属于漏报，如果是漏报就要立即补充规则。

在日志分析中要特别关注低频慢速攻击。这类攻击者每次只发送少量请求，间隔时间较长，试图避开频率限制和集中检测。WAF应开启基于会话和IP的累积行为分析，对一段时间内多次触发低危SQL注入规则的来源进行综合评分，达到阈值后自动升级处置动作。这种基于行为累积的检测思路，能有效应对那些单次请求看起来无害但整体行为明显恶意的攻击。

规则测试也是闭环中不可缺少的一环。每次调整WAF规则后，要用包含已知攻击Payload和正常业务请求的测试集进行回归验证。确保新规则能拦截目标攻击，同时不会误伤正常请求。测试集应持续扩充，把每次真实攻击中捕获的新Payload和业务方反馈的正常请求样本都纳入进来。只有经过充分测试的规则才能上线，避免因规则调整引入新的问题。

针对高价值接口实施专项防护策略

登录接口、搜索接口、数据导出接口、后台管理接口通常是SQL注入攻击的重点目标。对这些高价值接口，应在WAF中配置独立的防护策略，采用比普通接口更严格的检测规则和更低的容忍阈值。例如对登录接口的用户名和密码字段，除了常规SQL注入检测外，还可以增加长度限制、字符集白名单和格式校验。对搜索接口，可以限制单次搜索关键词的最大长度，对包含多个SQL关键字或特殊字符的请求直接拒绝。对数据导出接口，可以配置更严格的响应检测规则，防止攻击者通过注入批量拉取数据。

对于后台管理接口，建议在WAF层面配合IP白名单和访问频率限制。后台接口通常只允许特定管理员访问，如果WAF检测到来自非白名单IP的后台登录尝试，可以直接阻断。同时限制后台接口的请求频率，防止攻击者通过暴力尝试或自动化工具进行注入探测。这种网络层与业务层的联合限制，能大幅压缩攻击者的操作空间。

WAF的SQL注入防护能力不是买来就有的，而是靠持续配置优化和运营打磨出来的。从解码规范化到规则组合，从上下文感知到响应检测，从日志复盘到专项策略，每个环节都需要根据业务实际情况做针对性调整。只有把WAF当成一个需要持续投入的安全运营平台来对待，才能真正把SQL注入风险控制在可接受范围内。