SQL注入检测需用语法分析器解析AST而非正则匹配，重点检查WHERE/ORDER BY中的非常规嵌套SELECT或非法表达式；参数化查询为第一道防线，语法分析仅作补充，且须注意解析器兼容性与性能控制。
SQL注入检测不能只靠正则匹配
正则匹配 UNION SELECT、OR 1=1 这类特征，漏报率高且极易绕过。攻击者用注释符 --、/* */ 拆分关键字，或用大小写混写、URL编码、空格替换（如 %09、/**/）就能绕过。语法分析器的价值在于理解 SQL 的结构合法性，而非字符串表面相似性。
实操建议：
- 用成熟的 SQL 解析库（如 Python 的
sqlparse、Java 的JSqlParser）做前置解析，不是自己手写 parser - 解析失败 ≠ 一定有注入，但应标记为高风险请求，触发二次校验（如白名单参数比对、WAF联动）
- 注意解析器默认不校验语义（比如表名是否存在），仅校验语法结构；若需语义层防御，需结合数据库元信息做上下文补全
为什么 EXPLAIN + 语法树遍历比字符串扫描更可靠
真正有效的畸形检测，是看解析后 AST（抽象语法树）是否包含非常规组合：比如 WHERE 子句里出现嵌套的 SELECT 但不在允许位置，或 ORDER BY 后跟了非列名/数字的表达式（如 (SELECT 1)）。这类结构在合法业务 SQL 中极少出现，却正是盲注、报错注入的典型痕迹。
实操建议：
- 对解析出的 AST 做节点类型检查，重点监控：
SelectStatement是否嵌套在WhereClause或OrderByItem中 - 禁止
Function节点出现在排序/分组字段中（除非明确白名单如COUNT、MAX） - 注意 MySQL 8.0+ 支持 CTE（
WITH子句），旧版解析器可能无法识别，导致误判；务必确认解析器版本兼容目标数据库
参数化查询不是万能解药，但必须作为第一道防线
语法分析器再强，也无法替代参数化。它防不住所有注入变体（比如动态表名、列名、ORDER BY 字段），而这些恰恰是语法分析器容易“放过”的地方——因为它们本身语法合法。
实操建议：
- 所有用户输入进 SQL 的位置，优先走参数化；只有明确无法参数化的场景（如动态
ORDER BY column_name），才启用语法分析 + 白名单校验 - 白名单必须严格到具体值（如
['created_at', 'status']），不能只校验是否含字母数字 - 不要在应用层拼接 SQL 片段后再丢给解析器——拼接过程已破坏原始结构，解析结果不可信
生产环境部署时最常被忽略的三件事
语法分析器上线后，最容易在日志爆炸、性能抖动、误拦截业务请求这三点上栽跟头。
实操建议：
- 默认关闭全量 SQL 解析，只对高风险接口（如搜索、导出、报表）开启；用请求路径或 header 标识控制开关
- 设置解析超时（如
50ms），超时直接放行并告警，避免拖垮整个请求链路 - 记录原始 SQL 和解析错误详情到独立日志通道，别混进业务日志；否则排查误拦截时根本找不到上下文
语法分析器不是银弹，它擅长识别“长得不像人话”的 SQL，但对“伪装成正常人话”的注入（比如时间盲注里的 SLEEP(1)）无能为力。真要压住这类攻击，得靠行为建模和响应延迟监控，那又是另一层事了。
