时间盲注无法通过校验时间戳格式防御，必须用预处理语句绑定参数并监控响应时间——因攻击者利用时间戳作为探测载体，整数验证不阻止SQL拼接，延时函数仍可执行。
时间盲注攻击无法通过单纯校验时间戳格式来防御，必须配合预处理语句与响应时间控制——因为攻击者根本不需要篡改时间戳本身，而是利用它作为探测条件的载体。
为什么 filter_var(INPUT_GET, 'ts', FILTER_VALIDATE_INT) 对时间盲注无效
时间盲注不依赖时间戳是否“合法”，而依赖它是否被拼进 SQL 查询中参与逻辑判断。哪怕你用 FILTER_VALIDATE_INT 确认 ts 是整数，只要后续把它直接拼进 WHERE created_at > $ts 这类字符串里，攻击者就能注入 1234567890 AND SLEEP(5) 绕过验证。
-
FILTER_VALIDATE_INT只做类型守门员，不干预 SQL 构造过程 - 整数型输入照样可触发
SLEEP()、BENCHMARK()等延时函数 - 真正起作用的是让
ts值永远不参与 SQL 字符串拼接
如何安全使用时间戳参数参与查询
必须走预处理语句绑定，且时间戳字段在数据库中应为 DATETIME 或 INT 类型（非字符串），避免隐式类型转换绕过防护。
- 正确写法：
$stmt = $pdo->prepare("SELECT * FROM logs WHERE created_at > FROM_UNIXTIME(?)"); $stmt->execute([$ts]); - 若数据库存的是 Unix 时间戳整数，用
WHERE created_at > ?即可，无需函数包裹 - 禁止动态拼接
ORDER BY或GROUP BY字段名，时间相关排序需白名单控制（如只允许created_at、updated_at） - 对时间范围查询加硬限制，例如
WHERE created_at BETWEEN ? AND ?，两端都绑定参数
响应时间异常本身就是风险信号
即使用了预处理，若某接口平均响应时间突然从 20ms 拉长到 5s，大概率已在被时间盲注试探——这不是代码漏洞，而是业务逻辑暴露了可探测面。
立即学习“PHP免费学习笔记（深入）”；
- 在 Nginx 或 PHP-FPM 层配置请求超时（如
fastcgi_read_timeout 2s），强制中断长耗时响应 - 记录并告警单次请求 >1s 的 SQL 查询，尤其带
WHERE+ 用户输入时间参数的场景 - 避免在关键路径上执行
SLEEP()、WAITFOR等可控延时操作（哪怕只是调试用） - 对高频时间参数查询，考虑加缓存层（如 Redis），减少直连数据库频次
时间戳本身不是漏洞，但它是时间盲注最常借力的“支点”。防御的关键不在校验它多“真”，而在确保它永远不能成为 SQL 执行逻辑的开关——这要求你每一条含时间参数的查询，都经过预处理绑定，并接受响应时长监控的双重校验。
