SQL盲注难被日志发现因其不报错、无回显，仅靠延迟触发（如SLEEP），服务器返回200 OK，日志中无异常；需监控响应时间突增（如20ms→5020ms），在Nginx或APM层采样告警，限流熔断需结合X-Response-Time头与limit_req动态识别慢请求。
SQL盲注为什么难被日志发现
因为盲注不依赖报错或回显，攻击者靠 IF(SLEEP(5),1,0) 这类逻辑触发延迟，服务器返回 200 OK，日志里只有一行正常请求记录。你查 error_log 或 access_log 基本看不到异常——它根本没出错。
实操建议：
- 别只盯
500或SQL syntax error，盲注常藏在200响应里，且响应时间突增（比如平时 20ms，某次 5020ms） - 在 Web 服务器（如 Nginx）或应用网关层开启全量响应时间采样，阈值建议设为
1000ms，低于这个值的延迟波动太常见，高于才值得告警 - 避免在业务代码里用
microtime(true)手动打点——容易漏掉中间件、ORM、连接池等环节耗时，优先从反向代理或 APM 工具（如 OpenTelemetry + Jaeger）获取端到端延迟
怎么用 Nginx 实现请求限流+延迟熔断
Nginx 的 limit_req 能控频次，但默认不管响应时间；要防盲注，得让它“看到”慢请求并主动拦截。核心是结合 limit_req_status 和自定义响应头，再用 map 把慢响应映射成限流触发条件。
实操建议：
- 在
http块定义变量：map $upstream_http_x_response_time $slow_request { ~^[5-9][0-9]{3,}$ 1; default 0; }（匹配上游返回的X-Response-Time头，值 ≥5000ms 就标为慢请求） - 配置限流区：
limit_req_zone $binary_remote_addr$slow_request zone=sql_slow:10m rate=1r/m;
（把 IP + 是否慢请求作为 key，实现“同一 IP 若连续触发慢响应，就拉黑 1 分钟”） - 在
location中启用：limit_req zone=sql_slow burst=1 nodelay;
并确保后端服务返回X-Response-Time头（Laravel 用App\Http\Middleware\AddResponseHeaders，Express 用res.set('X-Response-Time', Date.now() - start)）
应用层加延迟监控的三个关键位置
光靠 Nginx 不够，盲注可能绕过代理直连 API 网关，或发生在内部微服务调用中。必须在数据库访问路径的关键节点埋点：驱动层、查询构造层、结果解析层。
实操建议：
- 在数据库驱动封装层（如 Python 的
pymysql包装类、Go 的sqlxHook）记录每条query的执行耗时，对超过1000ms的非批量操作打标并上报（注意过滤SELECT COUNT(*) FROM huge_table这类合理慢查） - ORM 查询构建阶段检查是否含可疑函数：正则匹配
/SLEEP\(|BENCHMARK\(|IF\([^,]+,[^,]+,[^)]+\)/i，命中则直接拒绝并记日志（不要只 warn，盲注探测往往是一次性试探） - 禁止在日志中打印原始 SQL 参数——
WHERE id = ?没问题，但WHERE id = '1 AND SLEEP(5)'打出来等于帮攻击者确认 payload 生效了；统一用占位符脱敏，或只记录参数类型与长度
为什么 WAF 规则对盲注效果有限
多数 WAF（如 ModSecurity）靠特征匹配，而盲注 payload 可以无限变形：SLEEP(5) → SELECT 1 FROM pg_sleep(5) → WAITFOR DELAY '0:0:5' → 甚至用 ELT(1, SLEEP(5)) 绕过关键词检测。规则越细，误杀越高；越粗，漏报越严重。
实操建议：
- 停用所有基于
SLEEP/BENCHMARK字符串的 WAF 规则，它们对现代盲注基本无效 - 改用行为分析：统计单个 IP 在 5 分钟内触发的
SELECT类型请求数，若 >30 且平均响应时间 >800ms，自动加入临时黑名单（比规则更适应变种） - 如果用云 WAF（如 Cloudflare），关闭 “SQL Injection” 默认策略，改开 “Rate Limiting” + “Custom Rule” 基于
cf.bot.management和响应时间联合判断，别信“智能防护”四个字
延迟监控和限流真正起作用的前提，是你的数据库查询本身有可测量的边界。如果业务里大量存在 SELECT * FROM users WHERE name LIKE '%?%' 这种没法加索引的模糊查询，再好的限流也只会把合法用户一起干掉——盲注防御不是加一层开关，而是逼你先把查询写干净。
