应重点监控request_uri、query_string、原始SQL字符串、matched_data等字段，结合语义化正则与多维度原始参数采集，通过ORM层埋点、数据库代理拦截及Flink CEP实现实时精准检测。
SQL注入检测该看哪些日志字段
真正能抓到可疑注入的，不是靠“有没有单引号”这种粗筛，而是看请求中是否出现典型攻击载荷与数据库交互模式的错位。比如 SELECT 出现在 URL 参数里、UNION SELECT 跟在 id=1 后面、或者 sleep(5) 这类延时函数被拼进参数——这些都不是业务逻辑该有的样子。
实操建议：
- 重点提取 Web 服务器日志中的
request_uri和query_string，不是只盯status或user_agent - 应用层（如 Java Spring）要开启
spring.sql.debug=true并捕获JdbcTemplate执行前的原始 SQL 字符串，否则你看到的全是预编译后的? - WAF 日志里别只信
rule_id，要核对matched_data字段内容，很多规则误报是因为正则把order by 1当成注入，其实只是前端排序参数
用正则匹配注入特征时为什么总漏报或狂告警
正则写得太宽，比如 ' OR '1'='1 这种经典 payload，如果只匹配 OR.*='，就会把 WHERE status = 'active' 也干掉；写得太窄，又漏掉 /**/UNION/**/SELECT 这种绕过变体。
实操建议：
- 优先用语义化规则：匹配
UNION后紧跟SELECT且中间无分号、无注释干扰（即非/*...*/或--包裹），再结合前后是否有数字型参数上下文 - 禁用模糊通配符
.*，改用字符集限定，例如匹配注释绕过写成(/**/|--)\s+(UNION|SELECT|SLEEP)，而不是.*UNION.* - 所有正则必须做负样本测试：拿真实业务 SQL（如
SELECT * FROM user WHERE name LIKE '%张%'）跑一遍，确认不触发
实时告警不能只依赖 Nginx 日志解析
Nginx 日志是异步刷盘的，从请求发生到日志落地可能延迟 200ms～2s，等你从日志里捞出 1' AND SLEEP(10)-- 再发告警，攻击者早就拿到数据了。真要实时，得在请求链路更上游卡住。
实操建议：
- 在 ORM 层埋点：Spring 的
DataSourceProxy或 MyBatis 的Interceptor，在prepareStatement前检查sql字符串是否含高危关键词+非常规结构（如多个SELECT、无空格拼接） - 数据库代理层（如 ProxySQL）开启
mysql-acl规则，直接拦截带information_schema或load_file的查询，比应用层更早一步 - 避免用 Logstash + Elasticsearch 做实时管道：ES 写入延迟不可控，改用 Kafka + Flink，让 Flink 的 CEP 引擎做事件序列匹配（例如“
id=1→id=1'→id=1' AND 1=1”三连击才告警）
为什么拦截后还要记录原始参数而非仅 SQL
单纯记录最终执行的 SQL（如 SELECT * FROM user WHERE id = ?）等于没记——你根本看不出攻击者传的是 id=1' UNION SELECT password FROM admin-- 还是 id=123。而只记 URL 参数又可能漏掉 POST body 或 header 注入（比如 X-API-Key: admin'--）。
实操建议：
- 必须同时采集三个维度：
http_method、raw_query_string、raw_post_body（开启client_body_buffer_size防截断），三者缺一不可 - 对敏感字段（如
password、token）做脱敏但保留结构，例如把pwd=abc123记为pwd=[REDACTED:6]，否则审计时无法判断是否被篡改 - 所有告警事件附加
trace_id，确保能反查完整调用链，不然你拦住了，却不知道这个请求是否已触发下游 Redis 缓存污染或消息队列投递
最麻烦的不是识别，是区分“试探性探测”和“已成功利用”。一次 id=1' 可能只是扫端口，但紧跟着 id=1' AND (SELECT COUNT(*) FROM users)>0-- 就该立刻熔断——这中间的节奏、频次、上下文，没法靠单条规则判断，得留够原始数据让运营人工复核。
