应通过数据库、应用、网关三层设防监控sql注入，重点识别异常模式而非单字符；数据库层过滤高危关键词并标记响应突增查询，网关层启用json解析并打标可疑流量，应用层埋点捕获orm及动态拼接等绕过行为。
监控生产环境中的 SQL 注入行为，不能靠事后翻日志猜，得在数据库、应用、网关三层设防，重点抓异常模式而非单个字符。
查数据库通用日志里的可疑查询模式
MySQL 的 general_log 或 PostgreSQL 的 log_statement = 'all' 开启后，能记录所有执行语句，但默认不启用——因为性能开销大。真要用于注入监控，必须配合过滤策略，否则日志爆炸且无意义。
- 只记录含高危关键词的语句：比如
UNION SELECT、information_schema、sleep(、waitfor delay、xp_cmdshell、OR 1=1（注意空格和大小写变体） - 避免用
LIKE '%union%'这种宽泛匹配，容易误杀搜索词；改用正则或分词后匹配完整 token - 对响应时间突增的查询做标记：盲注常用
BENCHMARK()或pg_sleep()拖延，可结合慢查询日志（long_query_time = 0.5）交叉比对
用应用层中间件拦截并打标异常请求
WAF 或自研 API 网关不是用来“挡掉所有注入”，而是把可疑流量打上标签、透传到下游，让应用自己决定怎么处理——比如拒绝、限流、或触发审计告警。
- WAF 默认不解析
Content-Type: application/json的 body，必须显式开启 JSON 解析策略，否则漏掉 70% 以上的现代 API 注入 - 不要依赖
OR 1=1这类原始特征，攻击者早用||1==1、OR+1%3D1、SeLeCt绕过；更可靠的是检测参数值是否含多层嵌套括号、非常规空格、或 base64 编码片段 - 对
GET /api/user?id=123和POST /api/user（body 含 JSON）需分别建规则，不能共用一套 query string 检测逻辑
从应用代码里埋点捕获未被拦截的绕过行为
最隐蔽的注入往往发生在 ORM 的 raw 查询、动态表名拼接、或日志打印语句里——这些地方 WAF 和数据库日志都看不到，只能靠代码层主动上报。
- 在所有调用
cursor.execute()（Python）、db.query()（Node.js）、session.createSQLQuery()（Hibernate）前加 hook，记录 SQL 模板 + 参数类型（字符串/数字/布尔） - 当发现某次查询的字符串参数里含 SQL 关键字（如
UNION），且该参数本应是邮箱或手机号，就立即发告警，而不是等它执行成功 - 禁用生产环境的
show_sql = true和错误堆栈回显，否则攻击者通过报错直接看到表结构——这比注入本身还危险
真正难监控的不是“有没有注入”，而是“有没有被绕过”。很多团队花了大力气配 WAF 规则，却没发现自己的健康检查接口因含 SELECT 1 被反复误杀，结果把真实攻击流量当噪音过滤掉了。监控的前提，是先看清你自己的合法流量长什么样。
