盲注SQL注入之所以难防，根本原因在于攻击者不直接读取报错信息或回显数据，而是通过构造布尔条件或时间延迟，利用应用程序响应差异逐字符推断数据库内容。传统基于正则匹配和特征签名的WAF规则在盲注面前几乎失效，因为请求本身看起来完全合法，参数值只是多了几个AND、OR、WAITFOR DELAY或者SLEEP函数。要真正拦截盲注，必须从请求意图识别、响应行为建模和会话级异常检测三个维度同时下手，而不是只盯着单条请求里的关键字。
盲注的核心特征不是payload长什么样，而是攻击者会在短时间内发送大量结构相似、参数值高度重复且仅个别字符变化的请求。比如同一个查询接口，攻击者会反复提交id=1 AND 1=1、id=1 AND 1=2、id=1 AND ASCII(SUBSTRING((SELECT password FROM users LIMIT 1),1,1))>100这类变体。这些请求单独看每一个都没有明显恶意特征，但放在一起就暴露出明显的枚举行为。因此第一层防护应当建立在请求频率和结构相似度分析上，对同一参数位置在短时间内出现大量仅谓词条件变化的请求进行聚类，一旦相似度超过阈值直接阻断或转入人机验证。
时间盲注的检测要更细。攻击者利用SLEEP、pg_sleep、WAITFOR DELAY等函数让数据库延迟响应，通过响应时间差判断条件真假。WAF不能只检测参数里有没有sleep关键字，因为攻击者可以轻易绕过，比如用BENCHMARK(10000000,SHA1('x'))、重复笛卡尔积连接、HEAVY查询或者利用数据库自身锁等待机制制造延迟。真正有效的做法是对每个数据库查询接口建立响应时间基线，当某个接口的响应时间突然从平均50毫秒飙升至3秒以上，并且同一会话内多次出现类似波动，就应当标记为时间盲注嫌疑。基线要按接口、按时间段动态更新，不能用一个全局固定阈值，否则业务高峰期正常慢查询会被误伤。
布尔盲注的检测难点在于响应内容差异可能极其细微。攻击者通过AND 1=1和AND 1=2让页面在正常显示和空白内容之间切换，或者让HTTP状态码在200和500之间跳变。WAF需要对比同一请求模板下多次响应的内容哈希、长度、状态码和DOM结构差异。如果发现同一参数位置的不同取值导致响应呈现二元化差异，且差异与参数值中的逻辑表达式结果相关，就可以判定为布尔盲注。这里的关键是响应差异分析不能只看长度，因为攻击者可能用注释或者HTML标签填充保持长度一致，需要结合结构指纹和语义特征。
更深层的拦截思路是把SQL语法解析前置到WAF层。与其依赖正则匹配已知攻击模式，不如对参数值进行SQL语法片段解析，判断其是否构成完整的条件表达式、子查询或者函数调用。攻击者为了绕过关键字过滤，会大量使用注释符、字符串拼接、十六进制编码、大小写混写、双重URL编码等手段。WAF需要在解码归一化之后，尝试将参数值还原为SQL语法树片段，如果发现该片段包含逻辑运算符、比较运算符、子查询或者时间控制函数，并且与原始参数类型不匹配，就应该提高风险等级。比如一个本应是数字ID的参数，却解析出了SELECT、UNION、CASE WHEN、SUBSTRING等结构，这本身就是强告警信号。
针对盲注的深度拦截不能只依赖请求侧检测，数据库侧的审计同样重要。很多盲注攻击即使绕过了WAF，也会在数据库日志中留下大量异常查询记录。通过旁路分析数据库慢查询日志和审计日志，可以发现同一来源IP或者同一会话在短时间内执行了大量结构相似但条件不同的SELECT语句，且这些语句的执行时间或返回行数呈现规律性差异。将数据库审计日志与WAF日志做关联分析，能够识别出那些WAF漏掉的盲注行为，并反向生成阻断规则。这种闭环机制比单纯堆砌WAF规则有效得多。
在实际部署中，盲注防护策略应当分层实施。第一层是协议和编码规范化，强制解码所有编码变体，拒绝畸形编码和过度编码的请求。第二层是输入结构校验，对每个参数定义严格的白名单格式，数字参数只允许纯数字，字符串参数限制长度和字符集，不符合的直接拒绝。第三层是行为分析，基于会话和IP维度统计请求频率、结构相似度和响应时间异常。第四层是SQL语法意图识别，对参数值进行语法片段解析和风险评分。第五层是数据库审计联动，利用旁路日志发现漏网攻击并动态更新规则。这五层不是各自独立，而是通过风险评分引擎串联，单层的高危信号可以直接阻断，多层的中危信号叠加后也能触发拦截。
有一个容易被忽视的点是盲注攻击常常利用HTTP参数污染和参数位置交换来绕过检测。攻击者会把注入payload拆分成多个参数，或者放在Cookie、User-Agent、Referer等非主流位置，甚至利用JSON和XML格式的嵌套结构。WAF如果只检测GET和POST的显式参数，会漏掉大量攻击。深度拦截要求对所有输入源一视同仁，包括Cookie、自定义Header、文件上传的文件名、JSON字段、XML节点等，统一提取并纳入风险分析。同时要处理参数重复出现的情况，不能只取第一个或最后一个值，而是要对所有值进行拼接和分别检测。
盲注攻击的自动化工具特征也很明显。sqlmap等工具在探测盲注时会先发送一系列基准请求确定正常响应，然后发送布尔探测请求观察差异，再发送时间探测请求确认延迟。这个探测序列本身具有固定的行为模式，比如请求间隔规律、参数值变化有序、User-Agent带有工具指纹等。WAF可以通过检测请求序列中的探测模式来提前识别攻击意图，而不必等到完整的盲注枚举过程展开。例如连续三次请求中参数值分别包含AND 1=1、AND 1=2、AND 1=1，且响应出现对应差异，就可以直接判定为自动化盲注探测，立即阻断该会话。
对于高价值目标，还可以引入动态令牌和查询签名机制。应用在生成页面时对每个查询参数附加一个短期有效的签名，WAF验证签名不通过就拒绝请求。这种方案能有效阻止自动化盲注工具，因为攻击者无法在脱离正常页面流程的情况下构造带有效签名的请求。不过该方案对应用改造要求较高，适合核心接口和敏感数据查询场景，不适合全站铺开。折中方案是对登录后的敏感操作启用签名校验，对公开查询接口依靠行为分析。
盲注防护的效果评估不能只看拦截率，还要看误报率和响应延迟。过于激进的规则会把正常用户的模糊查询、高级搜索和报表筛选误判为盲注。因此规则上线前需要用真实业务流量做回归测试，确保正常请求的通过率不低于99.9%。同时WAF引入的额外延迟应控制在毫秒级，否则会影响用户体验。对于时间盲注检测，响应时间基线的计算要排除网络波动和业务高峰期的影响，可以采用滑动窗口和中位数统计，而不是简单平均值。
最后要强调的是，盲注SQL注入的终极防线在应用代码本身。参数化查询和预编译语句能从根源上消除注入可能，WAF的深度拦截只是纵深防御中的一环。安全团队应当把WAF检测到的盲注行为作为应用漏洞的信号，推动开发团队修复存在注入风险的代码点。只有WAF拦截和应用修复双管齐下，才能真正降低盲注攻击的成功率。单纯依赖WAF规则更新永远追不上攻击者的绕过手法，基于行为分析和语法意图识别的深度拦截能显著提高攻击成本，但无法替代代码层的根本修复。
