时间盲注能绕过常规防护，因为它不依赖错误回显或页面变化，仅通过SLEEP()等延时函数触发响应延迟，只要数据库支持且未限制查询耗时，攻击者即可逐字节还原数据。
时间盲注为什么能绕过常规防护
因为时间盲注不依赖错误回显或页面内容变化，只靠 SLEEP()、BENCHMARK() 或 IF() + 延时函数触发响应延迟，只要数据库支持执行这类函数，且应用未限制查询耗时，攻击者就能通过测量 HTTP 响应时间逐字节还原数据。常见于登录、搜索、订单查询等看似“安全”的接口——它们往往关闭了错误提示，却没做查询超时控制。
关键防御点：从数据库层掐断延时函数执行
最直接有效的做法是禁止数据库用户使用延时类函数。MySQL 中需检查并移除对应权限：
- 确认当前应用数据库账号无
EXECUTE权限（该权限允许调用存储过程/函数，而SLEEP()是系统函数） - 撤销
SELECT以外的高危权限：REVOKE EXECUTE ON *.* FROM 'app_user'@'%'; - 禁用特定函数（MySQL 8.0+ 支持）：
SET GLOBAL log_builtin_as_functions = OFF;并在配置中设disabled_storage_engines = "blackhole,archive,example"（虽不直接禁SLEEP，但可限制攻击面）
注意：仅靠 mysqli_real_escape_string() 或简单过滤单引号无法阻止时间盲注，因为 ' AND SLEEP(5)-- 中的单引号已被合法闭合，逃逸完全成功。
应用层必须加查询超时与行为监控
即使数据库层做了限制，攻击者仍可能用 BENCHMARK(1000000,SHA1('test')) 这类 CPU 耗尽型 payload 触发延迟。因此应用层要主动干预：
- 所有数据库查询强制设置超时，例如 PDO 中：
$pdo->setAttribute(PDO::ATTR_TIMEOUT, 2);；MySQLi 中：mysqli_options($conn, MYSQLI_OPT_CONNECT_TIMEOUT, 2); - 记录慢查询日志（阈值建议 ≤1s），重点监控含
SLEEP、BENCHMARK、IF、ELT的 SQL 模式 - 对同一 IP 在 60 秒内触发 ≥3 次超时查询的请求，自动临时封禁或要求验证码
别依赖 WAF 规则匹配 SLEEP(5) —— 攻击者会用 URL 编码、十六进制、或嵌套写法如 0x534C454550283529 绕过。
参数化查询不能替代超时控制
参数化查询（如 prepare("SELECT * FROM users WHERE id = ?")）确实能彻底阻断时间盲注的注入入口，但它只对“用户输入参与 WHERE / ORDER BY / LIMIT 等位置”有效。而以下场景仍危险：
- 动态表名/字段名拼接（如
"SELECT * FROM " . $_GET['table']） - ORDER BY 后直接插变量（
"ORDER BY " . $_GET['sort']），即使用了预编译也无法绑定列名 - 存储过程调用中传入未校验的参数（
CALL get_user(?)但过程体内又拼 SQL）
这些地方必须配合白名单校验（如 in_array($_GET['sort'], ['id', 'name', 'created_at'])）+ 查询超时双保险。时间盲注最难察觉，往往日志里只有“慢查询”，没有报错，也无异常返回内容。
