如何检测SQL注入行为_建立实时告警机制拦截风险

应重点监控 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-- 就该立刻熔断——这中间的节奏、频次、上下文，没法靠单条规则判断，得留够原始数据让运营人工复核。