布尔盲注与时间盲注威胁更大，根本原因在于二者可在完全关闭错误回显、无联合查询入口、无报错信息的“加固”环境下持续生效，而该环境恰是开发者易误判为“已安全”的高危场景。
布尔型盲注和时间型盲注对SQL安全威胁更大，根本原因在于：它们能在**完全关闭错误回显、无联合查询入口、无报错信息泄露**的“加固”环境下持续生效——而这类环境恰恰是开发者最容易误以为“已安全”的场景。
布尔盲注依赖页面状态差异，但极易被误判为“无漏洞”
很多开发团队在上线前会做两件事：关掉 display_errors、统一返回“操作失败”页面。这看似封堵了报错注入，却给布尔盲注留下完整通路。
- 典型误判：输入
id=1' AND 1=1--和id=1' AND 1=2--后，页面都显示“未找到内容”，就断定没漏洞——但实际可能是前后端逻辑把空结果和语法错误都映射到了同一提示文案 - 真正关键点在于区分“数据不存在”和“SQL执行失败”：前者是业务逻辑返回，后者是数据库层中断；但前端渲染时二者常被合并处理
- MySQL 的
substring()、ascii()、PostgreSQL 的substr()+get_byte()都能构造稳定真假分支，且不触发报错
时间盲注绕过所有内容检测，只依赖响应延迟
时间盲注不依赖任何页面文本变化，只靠 SLEEP(5) 或 BENCHMARK(1000000,ENCODE('a','b')) 这类函数拖慢响应——这意味着 WAF、内容过滤、模板引擎甚至 CDN 都无法拦截有效载荷。
- 常见疏漏：
mysqli_query()默认不限制执行时间，max_execution_time是 PHP 层限制，不影响 MySQL 内部 sleep - PostgreSQL 中
pg_sleep(5)、SQL Server 中WAITFOR DELAY '0:0:5'同样有效，且语法差异大，规则型 WAF 很难全覆盖 - 真实攻击中常混用：先用布尔盲注确认字段长度，再用时间盲注逐字爆破，规避频率监控
两者共同放大“低权限账户”的危害
当数据库账号被严格限制（如仅 SELECT 权限、禁用 UNION、禁用 information_schema 查询），常规注入基本失效。但布尔/时间盲注仍可工作：
- 不需要
UNION：靠子查询 + 布尔判断即可，例如AND (SELECT COUNT(*) FROM users) > 0 - 不需要读取系统表：可用
(SELECT table_name FROM information_schema.tables LIMIT 1 OFFSET 0)逐个猜，只要权限允许查information_schema就行（而该库多数只读账号默认可查） - 盲注本质是“穷举+信道”，只要存在一个可控输入点 + 一个可观测输出维度（真/假或快/慢），就构成完整攻击链
最危险的是那种“前端返回 200 状态码、后端日志里只有 SQL 异常堆栈、运维认为‘没数据泄露就是安全’”的系统——它对布尔和时间盲注几乎不设防，而攻击者只需要一个能发 HTTP 请求的终端，就能在几小时内拿到管理员密码哈希。
