首页/安全/漏洞与攻击面速查/盲注场景的监控与处置
Web 漏洞原理与防护55 条

盲注场景的监控与处置

无可回显的注入通常依赖布尔差异或响应时间判断,业务侧难以及时感知;监控应以数据库慢查询与请求模式为线索,处置仍以参数化改造为主。

漏洞与攻击面速查安全更新于 2026-10-13

盲注难在哪

盲注指没有直接回显的 SQL 注入:页面不返回查询结果也不报错,攻击者改用布尔条件的真假差异(内容长度、状态码)或时间延迟(SLEEP、BENCHMARK)逐字符推测数据。因为单次请求看起来完全正常,业务侧靠错误日志基本发现不了,只能从请求模式、响应时间分布和数据库负载三处找线索。

基本信息

注入类型布尔盲注、时间盲注、带外(DNS/HTTP)盲注
典型特征参数微小变化 + 高频重复请求
数据库线索慢查询日志重复语句、连接数与负载升高
Web 线索响应时间阶梯差异、同一接口被同一来源高频访问
修复手段参数化查询(预编译)为主,输入校验与最小权限为辅
定级依据被探测接口是否可访问敏感数据

监控线索对照

线索可能含义误报来源
同一来源高频访问同一接口自动化逐字符探测健康检查与监控探针
响应时间稳定阶梯差异条件判断命中与否后端缓存抖动、冷热数据
慢查询日志重复出现同一语句模板逐字符推测批量数据处理任务
请求量平稳但数据库负载升高注入语句消耗资源统计与报表任务
带外 DNS 请求异常增多带外盲注外传数据第三方 SDK 回调域名
UA 与参数编码异常自动化工具特征老客户端兼容请求

数据库侧监控线索

数据库侧监控线索
-- 确认慢查询日志是否开启(MySQL 8.0)
SHOW VARIABLES LIKE 'slow_query_log%';
SHOW VARIABLES LIKE 'long_query_time';
-- 关注异常查询的来源主机分布,看是否集中来自单一应用
SELECT user_host, COUNT(*) AS cnt FROM mysql.slow_log GROUP BY user_host ORDER BY cnt DESC LIMIT 20;
-- 用语句摘要看重复度最高的语句模板
SELECT DIGEST_TEXT, COUNT_STAR, AVG_TIMER_WAIT FROM performance_schema.events_statements_summary_by_digest ORDER BY COUNT_STAR DESC LIMIT 20;

Web 侧线索

Web 侧线索
# 同一接口被同一来源高频访问,参数仅细微变化
# 响应时间出现稳定的阶梯式差异,这是盲注最典型的特征
# 错误率平稳但数据库负载升高
# 请求间隔规律,像脚本按字符位逐个探测
# UA 或参数编码异常,与真实用户行为不符

典型使用场景

  • 应急研判:区分这是扫描器批量探测还是针对性的真实利用
  • 日常运营:给高价值接口补上请求频率与响应时间基线
  • 修复后回归:用同一组探测请求验证注入是否真的被拦下
  • 出具报告:说明检测依据与证据链,而不是只给一个告警标题
  • 与 WAF 告警关联:核对拦截日志与数据库侧负载是否吻合
  • 容量规划:评估盲注探测对数据库的实际压力
修复以代码参数化为主;WAF 只能降低被探测频率,不能替代修复,审计时也不会被认定为整改完成。
盲注不需要回显就能逐步拖走数据。不要因为「没看到报错、页面正常」就判定为误报,先看请求模式与响应时间分布再下结论。

易错点

  • 只加 WAF 不改代码:规则被绕过时漏洞依旧存在,审计时也会被判定未整改
  • 拿响应时间差异当唯一证据,缓存抖动与网络抖动会造成大量误报
  • 慢查询日志默认关闭,事件发生后才想起要查,已无数据可取
  • 只按告警数量排序,不判断被探测接口是否真的能取到敏感数据,优先级失真
  • 修复后只做功能回归、不做注入回归,上线后被改回不安全写法

数据来源与参考

  • MySQL 8.0 Reference Manual(slow query log)
  • OWASP WSTG SQL Injection 章节
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌