“偏离基线”的查询指通过聚合窗口对用户/ip/接口维度的历史行为建模，动态监测参数长度分布、特殊字符密度、sql结构特征频率三类统计量，单条日志无异常但滑动窗口可识别攻击节奏并触发告警。
直接看日志里“偏离基线”的查询，不是靠关键词匹配——基线建模才是大数据平台防SQL注入的核心能力。
怎么定义“正常查询行为”基线
基线不是静态阈值，而是对每个用户/IP/接口维度的历史行为建模。重点盯三类统计量：
- 参数长度分布：比如搜索框95%的输入在1–20字符，突然出现长度>100的请求需标记
- 特殊字符密度：单引号
'在正常登录参数中出现频次≈0.02次/请求，若某IP连续5次请求中该值≥0.8，大概率在fuzz - SQL结构特征频率：如
ORDER BY后接数字在正常排序请求中多为1–5，若日志中频繁出现ORDER BY 999或ORDER BY (SELECT 1)，属强可疑信号
为什么用聚合窗口（而非单条日志）做判断
单条日志看不出异常，但滑动窗口能暴露攻击节奏。例如：
- 同一
user_id在5分钟内发起17次含UNION SELECT的请求 → 超过该用户历史P99值（2次）→ 触发告警 - 某API路径
/api/search过去24小时平均响应时间86ms，当前1分钟内有6次请求耗时>3000ms且含SLEEP() → 时间差盲注特征成立
- 不同IP共用相同payload变体（如
' OR '1'='1、<code>" OR "1"="1、) OR 1=1--）在10秒内集中出现 → 工具扫库行为
哪些字段必须进特征工程（否则基线失效）
只分析原始SQL文本会漏掉大量上下文。真正有效的特征至少包含：
- 请求来源：
http_referer是否为空或非常规（如非本站域名） - 客户端指纹：
User-Agent含sqlmap、curl或无UA → 非浏览器流量 - 参数位置标记：区分GET参数、POST body、
Cookie、X-Forwarded-For等不同注入面，因为防御强度常不一致 - 响应反馈信号：HTTP状态码突变（如200→500）、响应体含
MySQL/ORA-/SQL syntax等错误字串（即使WAF拦截，也应记录403响应中的X-WAF-Info头）
基线模型最易被忽略的点：它必须随业务迭代自动漂移。比如新上线一个支持LIKE '%xxx%'的搜索功能，%字符密度会自然上升——不重训模型，就会把合法流量当攻击打。
