正则表达式不适合核心防护SQL注入，因其无法应对变体多、上下文敏感、编码绕过、嵌套注释及跨变量拼接等复杂场景，仅宜作轻量预检或辅助工具。
正则表达式可用于初步识别 SQL 注入常见特征，但不能单独用于可靠、生产级的 SQL 注入实时静态扫描与拦截。它仅适合做轻量预检、日志筛查或开发辅助工具，无法替代参数化查询、WAF 或语法解析器等真正安全机制。
为什么正则表达式不适合核心防护
SQL 注入变体极多，上下文敏感，正则难以覆盖所有情况：
- 合法 SQL 中可能包含看似危险的字符串（如字段名含
or、注释符--出现在字符串内） - 编码绕过（
%27、%u0027、Unicode 混淆、大小写变形：SeLeCt） - 嵌套注释、换行、空白符干扰（
UNION/**/SELECT） - 动态拼接场景下，恶意片段可能分散在多个变量中，正则无法跨上下文关联
可谨慎使用的正则检测模式（仅作辅助）
若用于日志告警、IDE 插件提示或测试环境粗筛，可参考以下保守规则（以 PCRE/Python re 为例）：
-
基础单引号/双引号未闭合：
r"[^\](['"])(?!(?:[^'"\]*\.)*[^'"\]*)"（需配合转义处理） -
常见注入关键字 + 注释/空格组合：
r"(unions+select|selects+*s+from|inserts+into.*values|drops+table|;--|*/s*--)（忽略大小写，但易误报） -
内联注释干扰：
r"/*!.*?*/"匹配 MySQL 内联注释（常被用于绕过 WAF）
⚠️ 注意：必须对输入先做 URL 解码、Unicode 规范化，并限制匹配长度，避免回溯灾难。
更合理的静态扫描实践路径
真正有效的静态扫描应结合结构化分析：
- 使用 AST（抽象语法树）解析 SQL 字符串（如 Python 的
sqlglot、sqlparse），识别未参数化的字面量拼接点 - 在代码层标记高危函数调用（如
cursor.execute(sql + user_input)），而非匹配 SQL 片段 - 结合污点追踪（Taint Analysis），从用户输入源（request.args、form）出发，检查是否未经转义/参数化进入 SQL 执行点
- 将正则作为“快速失败”过滤器前置，命中后再交由 AST 或污点引擎深度分析
实时拦截应依赖运行时机制
静态扫描无法实现“实时拦截”，真正的实时防护需在运行时完成：
- Web 应用防火墙（WAF）如 ModSecurity，内置基于规则+异常检测的 SQLi 模块（仍非绝对可靠）
- 数据库代理层（如 ProxySQL、MySQL Router）配置 SQL 语法白名单或执行计划校验
- 应用层强制使用预编译语句（PreparedStatement）或 ORM 参数化接口，从源头杜绝拼接
正则可嵌入 WAF 规则集作初筛，但必须配合响应头检查、状态码分析、延迟盲注行为建模等多维判断。
