盲注攻击难被发现是因为其不回显错误或数据，仅通过响应时间、状态码或页面细微变化（如SLEEP延迟、布尔差异）间接推断信息，日志中仅显示正常200响应，无异常痕迹。
盲注攻击为什么难被发现？
盲注（Blind SQL Injection）不回显错误或查询结果，攻击者靠响应时间、HTTP状态码或页面细微变化来推断数据，比如用 SLEEP(5) 判断条件真假，或用 AND SUBSTRING(password,1,1)='a' 逐字猜解。传统日志里只看到正常200响应，没有报错信息，开发和运维很难从表面察觉异常。
WAF如何识别并拦截盲注特征？
现代WAF（如 ModSecurity、阿里云WAF、腾讯云WAF）不是靠“看到完整SQL语句”来判断，而是基于行为模式和语义规则做动态检测：
- 检测延时类函数：匹配
SLEEP、BENCHMARK、WAITFOR等关键词及其变体（如大小写混写、URL编码、嵌套括号） - 识别布尔逻辑探测：对高频出现的
AND 1=1、OR 2>1、AND SUBSTRING、AND ASCII组合做上下文分析 - 监控响应差异：部分高级WAF支持基线建模，当同一接口在参数微调后返回内容长度突变或响应时间明显拉长（如 >2s），触发告警或拦截
- 限制请求频率与深度：对单IP在短时间内发起大量相似结构的GET/POST请求（如
id=1 AND 1=1、id=1 AND 1=2轮询），直接限流或封禁
WAF规则配置中容易忽略的三个坑
开WAF不等于防住盲注，很多团队开了但没调对规则，导致漏拦或误杀：
-
strict模式下默认规则组可能未启用“时间盲注检测”，需手动开启rule_id: 942100（ModSecurity CRS）或对应云厂商的“延时型注入防护”开关 - 前端用了CDN或反向代理（如 Nginx），若未开启
X-Forwarded-For透传，WAF看到的全是CDN IP，无法做IP维度限频，攻击流量会绕过策略 - API接口返回JSON，而WAF默认只检查HTML响应体，需确认规则是否覆盖
Content-Type: application/json的响应解析逻辑，否则盲注探测的布尔反馈（如{"success":true}vs{"success":false}）可能被忽略
WAF只是辅助，不能替代代码层防御
盲注能成功，根本原因还是后端用了拼接SQL且没参数化。WAF拦得住 id=1 AND SLEEP(5)，但拦不住你代码里写 "SELECT * FROM user WHERE id = " + request.query.id —— 因为这个请求本身完全合法，WAF看不到内部执行逻辑。真正卡住盲注入口的，永远是预处理语句 + 最小权限数据库账号 + 错误信息不回显。WAF的价值在于给修复窗口期：它帮你先挡住扫描器批量试探，让你有时间把 mysql_query 换成 mysqli_prepare。
