盲注无法靠统一错误页修复，因其不依赖错误内容，而是通过响应时间、状态码、页面长度等细微差异推断数据；真正防护需确保所有请求在服务端行为完全一致。
盲注为什么不能靠“统一错误页”修复
统一返回 500 页面或跳转到固定提示页，对布尔型或时间型盲注基本无效。攻击者不依赖报错内容，而是通过响应时间、HTTP 状态码、页面长度或 DOM 结构的细微差异来推断数据——这些差异不会因错误页统一而消失。
常见误判是：只要不显示 MySQL error 或 ORA-00917 就安全了。但盲注根本不需要这些信息。
- 布尔盲注靠
and 1=1与and 1=2的页面是否“看起来一样”来判断真假 - 时间盲注靠
SLEEP(5)或BENCHMARK()是否导致响应延迟 - 即使所有请求都返回 200 + 同一 HTML 模板，只要响应体长度差几个字节（比如少输出一个用户名），就可能被自动化工具识别
真正有效的盲注防护必须切断响应差异
核心思路不是“掩盖错误”，而是让合法请求和恶意探测在服务端行为上完全一致：相同输入参数 → 相同数据库操作 → 相同响应时间 → 相同输出长度 → 相同状态码。
- 禁用所有基于业务逻辑的条件分支返回，例如：
if (user_exists) { render_profile(); } else { render_404(); }→ 改为统一渲染空模板 + 固定 HTTP 状态码（如始终 200） - 对所有带参数的查询，强制使用参数化查询（
PreparedStatement/query.bind()），杜绝拼接 SQL - 禁用数据库层的报错透出，但更要禁用应用层根据查询结果做差异化响应（如“用户不存在”和“密码错误”返回不同提示）
- 对可能触发盲注探测的字段（如
id、username、token），统一加白名单校验或正则过滤（如id只允许/^\d+$/）
时间盲注特别要注意的性能陷阱
SLEEP() 类探测之所以有效，是因为数据库执行耗时直接反映到 HTTP 响应上。哪怕你屏蔽了报错、统一了页面，只要服务端执行了带延时的 SQL，攻击者就能测出来。
- 避免在用户可控参数参与的 WHERE 条件中使用
LIKE '%xxx%'、REGEXP、全文索引等低效操作——它们本身就会造成时间波动，容易被当成盲注信号 - 禁止在应用代码里手动调用
Thread.sleep()、time.sleep()或执行WAITFOR DELAY等语句做“防刷”或“限速” - 数据库连接池要配置合理超时（如
socketTimeout=3000），防止恶意SLEEP(30)拖垮连接数 - Web 服务器（如 Nginx）开启
proxy_read_timeout限制后端响应上限，但注意这只能缓解，不能替代服务端防护
布尔盲注最难察觉的泄露点
最隐蔽的布尔差异往往不在 HTML 内容里，而在 HTTP 头、Cookie、重定向地址或响应体末尾的空白字符中。
- 检查是否无意中在 JSON 响应里返回了
"exists": truevs"exists": false—— 这就是典型的布尔盲注入口 - 确认所有接口返回的 Content-Length 是否恒定（可用 curl -I 测），尤其注意模板引擎是否因变量为空而少渲染一行或一个空格
- 避免用
count(*) > 0做存在性判断后返回不同结构；改用固定结构 + 默认值填充（如始终返回{"user": {...}}，查无结果时user为null） - 日志里不要记录 “found 0 rows” 和 “found 1 row” 这类可被侧信道利用的信息
if (id == 1) { trigger_alert(); }，就可能成为整个系统盲注防御的突破口。
