布尔盲注难以被waf检测，因其不触发错误日志、不改变http状态码，仅通过页面内容微小差异或响应时间波动传递信息；waf依赖报错关键词、异常状态码或明显注入模式匹配，而布尔盲注使用合法函数（如substring、ascii）和条件语句，特征稀释且语义隐晦，导致规则库普遍放行。
布尔盲注不触发错误日志，WAF很难抓到有效特征
大多数Web应用防火墙（WAF）依赖报错关键词（如 SQL syntax、mysql_fetch）、异常响应码（500）、或明显注入模式（如 UNION SELECT）做规则匹配。而布尔盲注全程不报错、不回显数据、不改变HTTP状态码——只靠页面内容微小差异（比如多一行“Welcome”，少一个
常见错误现象：开启WAF后，' OR 1=1 -- 被拦截，但 ' AND SUBSTRING(database(),1,1)='a' -- 却能反复通过。这不是WAF失效，而是它根本没把这类语句归为高危模式。
- WAF规则库普遍对布尔型条件语句（
AND/OR+ 比较操作）放行宽松，因为合法业务逻辑里大量存在 - 数据库函数如
SUBSTRING()、ASCII()、LENGTH()在白名单中常被忽略，不被视为敏感调用 - 攻击者可将payload拆成多段、用大小写混用（
SubStRiNg()）、或插入无害空格/注释，进一步稀释特征
参数化查询能防住，但很多老系统根本没用
布尔盲注本身不是“绕过”参数化查询，而是专门针对**未使用参数化查询**的拼接式SQL代码。只要后端还用 username = "' + request.getParameter('u') + '" 这类写法，无论是否报错，布尔盲注都天然成立。
真实场景中，大量遗留PHP/Java/ASP系统仍依赖手动拼接+简单过滤（比如只删单引号），这类代码面对 ' AND 1=1 -- 和 ' AND (SELECT COUNT(*) FROM users)=123 -- 完全等效——数据库照常执行，应用照常返回“Right”或“Wrong”。
- 参数化查询强制将输入作为纯数据绑定，
SUBSTRING()这类函数只能出现在SQL模板里，用户输入进不去执行上下文 - ORM框架（如MyBatis的
#{}、Hibernate的JPQL）若配置不当（比如误用${}拼接），同样会失效 - 即使用了预编译，若开发人员在SQL里动态拼接表名/字段名（
WHERE " + sortField + " = ?），布尔盲注仍可作用于这部分
响应差异太细微，自动化检测工具容易漏判
布尔盲注依赖人眼或脚本比对两次请求的响应体差异：可能只是HTML里某个标签的class从success变成error，或者JSON里"valid": true变成false。这种变化对Burp Suite的对比功能或sqlmap的--level 3 --risk 2默认策略来说，噪声太大、置信度太低。
典型漏判场景：
- 目标页面启用了CDN或服务端压缩（gzip），导致两次响应body字节长度一致，但实际内容不同
- 前端JavaScript根据后端返回的布尔值动态渲染，原始HTTP响应体完全一样
- 应用统一返回200，且错误/成功页仅靠JS跳转或CSS隐藏元素区分
这时候，sqlmap -u "http://x.com?id=1" --technique=B 可能直接跳过布尔盲注测试，转而尝试更“显眼”的时间盲注。
防御时最容易被忽略的点：不只是SQL层，前端和缓存也在帮倒忙
开发者常以为“只要SQL安全就万事大吉”，但布尔盲注的成功往往卡在更上游：前端把错误状态硬编码进HTML，或CDN缓存了“Wrong”响应却没按参数缓存，导致所有注入判断都返回同一个结果。
例如，某登录接口返回：{"status":"fail","message":"Invalid credentials"}，但无论用户名是否存在，message字段永远不变——这就让布尔盲注失去判断依据。反过来，如果后端对不存在的ID返回404，存在的ID返回200，那连id=1 AND 1=1都能直接暴露注入点。
- 检查所有API响应体、HTTP状态码、响应头（如
X-Debug）、甚至重定向Location是否随输入变化 - 禁用CDN对带查询参数的GET请求做泛缓存；必须缓存时，确保
Cache-Control: no-cache或按id等关键参数做key - 避免前端用
if (res.data.status === 'success')这种弱判断，应要求后端提供明确、不可伪造的布尔信号（如"exists": true）
真正难防的不是布尔盲注本身，而是它迫使你检查整个请求生命周期里每一处“隐式反馈”。一个看似无关的404、一段被缓存的HTML、甚至浏览器开发者工具里Network面板的时间抖动，都可能是突破口。
