sql注入绕过waf的典型特征包括：同一请求含order by+数字参数+响应时间突增；where后出现成对布尔表达式且响应差异明显；url/post中高频出现/**/、%00等混淆字符；单ip分钟内对同一接口发起超5次不同payload请求。
SQL注入绕过防火墙的典型特征有哪些
WAF（Web应用防火墙）对 UNION SELECT、SELECT ... FROM information_schema 这类显式关键词拦截很严，但攻击者常改用语义等价、结构分散的方式绕过。比如用大小写混写（SeLeCt）、内联注释（SELECT/*a*/1）、URL编码（%20%2b 替代空格加号）、或利用函数别名（sleep() 换成 benchmark(1000000,sha1('a'))）。这些手法本身不触发规则库关键词匹配，却仍能达成注入效果。
真正值得盯住的不是“有没有 SELECT”，而是请求中是否出现以下组合信号：
- 同一请求里同时含
ORDER BY+ 数字参数 + 后续响应时间突增（暗示盲注探测） -
WHERE子句后跟非预期的布尔表达式，如id=1 AND 1=1和id=1 AND 1=2成对出现且响应码/长度差异明显 - URL 或 POST body 中高频出现
/**/、/*!*/、%00、%23（#）等用于混淆或截断的字符序列 - 单个 IP 在 1 分钟内发起 >5 次带不同 payload 的相同接口请求（例如
/api/user?id=1→?id=1 AND SLEEP(1)→?id=1 AND BENCHMARK(...)）
如何用流量日志做轻量级异常检测
不需要部署完整 SIEM，用 Nginx 日志 + 简单脚本就能筛出可疑模式。关键是把原始日志转成结构化字段（如 $request_uri、$body_bytes_sent、$request_time），再按会话/IP 聚合分析。
示例：用 awk 快速统计某接口的响应时间离散度
awk '$7 ~ /^\/api\/user/ {print $1, $9, $NF}' access.log | \
sort | \
awk '{ip[$1]++; time[$1] += $2; max[$1] = ($2 > max[$1] ? $2 : max[$1]); min[$1] = (NR==1 || $2 0.8) print i, "time range:", max[i]-min[i]}'
这个逻辑抓住的是「同一 IP 对同一路径的响应时间波动超过 800ms」——盲注常用 SLEEP() 或 BENCHMARK() 拉长响应，时间差就是最廉价的特征。
更进一步可加：length($7) > 200（超长 URI 常含嵌套编码）、$9 ~ /200|304/ && $NF （返回 200 却只发回极短 body，可能是报错注入触发了错误页面截断）
为什么正则规则容易漏掉真实攻击
靠写正则匹配 SELECT.*FROM 这类规则，在实战中基本失效。原因很实在：
- WAF 规则更新滞后，而攻击者用
EXTRACTVALUE、UPDATEXML、GTID_SUBSET等 MySQL 特有函数做报错注入，根本不出现SELECT - HTTP 参数值经过多层解码（URL decode → JSON unquote → SQL parser 再解析），正则若只扫原始字符串，会错过最终拼进 SQL 的部分
- 合法业务也可能触发类似特征：前端埋点上报带
/**/注释的调试参数、低代码平台生成的动态 SQL 含大量空格和换行
所以纯规则引擎必须搭配行为基线。比如记录每个接口正常请求的平均 request_time、body_bytes_sent、URI 长度分布，偏离 3σ 就标为高风险，而不是死守「有没有 UNION」。
实际部署时最容易被忽略的环节
很多人在日志里加了 $request_body，却发现 POST 请求体始终为空。这是因为 Nginx 默认不缓存 request body，需显式配置：client_body_buffer_size 16k; + client_max_body_size 1m;，且仅对 POST 和 PUT 生效；还要注意如果用了 CDN 或 LB，原始 body 可能已被剥离，得在最靠近应用的那层 Nginx 开启。
另一个隐形坑是时间戳精度：$request_time 是毫秒级浮点数，但某些日志收集 agent（如 Filebeat）默认截断小数位，导致 SLEEP(1) 和 SLEEP(0.1) 看起来一样。务必确认 pipeline 中未做无损格式转换。
特征工程比模型选择更关键——没对齐真实攻击链路的指标，再好的 LSTM 也学不出东西。
