新型SQL注入无法靠固定规则或一次性改造防御，必须动态响应；参数化查询是基线但非万能，堆叠注入、二阶注入、函数绕过及动态语句仍可突破；防御需覆盖输入—存储—执行全链路，对所有外部数据源（库、Redis、文件、MQ）在SQL构造前重新校验；应禁用原始执行函数、收口至封装层、白名单SQL模板，并基于解析树语义分析而非正则匹配检测异常。
靠一套固定规则或一次性的参数化改造，挡不住新型SQL注入。防御必须能随攻击演化而动态响应。
参数化查询不是万能解药，但仍是不可替代的基线
很多团队以为用了 PreparedStatement 或 MyBatis 的 #{} 就高枕无忧，其实不然。堆叠注入（; 分隔多语句）、二阶注入（恶意数据先入库、后续逻辑再拼接执行）、以及利用 JSON_EXTRACT、XMLQUERY 等新型函数绕过预编译边界的情况，都可能让参数化失效。
- MySQL 8.0+ 支持
PREPARE ... EXECUTE动态语句，若变量来自数据库字段而非前端输入，仍可能触发注入 - PostgreSQL 中
EXECUTE 'SELECT * FROM ' || table_name这类拼接，哪怕参数化了WHERE条件也无济于事 - ORM 框架如 Hibernate 的
@Query(native = true)若含字符串拼接，#{}同样不生效
防御层要覆盖“输入—存储—执行”全链路
传统防护只盯住 HTTP 请求入口，但攻击常在更下游爆发。比如用户昵称存入数据库时被过滤，但后台导出报表时用该昵称拼接 SQL；或日志分析脚本读取数据库字段后直接 eval() 执行——这类场景下，输入时的过滤和参数化毫无意义。
- 对所有从数据库、Redis、文件、MQ 拉取的数据，在用于构造 SQL 前，必须重新校验/转义，不能默认“已清洗”
- 禁用
mysql_query()、pg_query()等原始执行函数，统一收口到封装层，强制走参数化路径 - 敏感操作（如 DROP、TRUNCATE、UNION SELECT）应配置白名单 SQL 模板，运行时仅允许填充值，不允许变更结构
规则引擎需支持运行时特征识别，而非静态关键字匹配
现代 WAF 或数据库代理（如 ProxySQL、ShardingSphere-Proxy）若还依赖 SELECT.*FROM.*UNION 这类正则规则，早被变形编码、注释混淆、大小写混用绕过了。真正有效的检测，得基于 SQL 解析树做语义分析。
- 识别非常规的嵌套层级：如
SELECT (SELECT (SELECT ...))多层子查询可能用于盲注探测 - 监控非业务时段高频出现的
SLEEP()、BENCHMARK()、WAITFOR等延时函数调用 - 标记同一会话中连续出现的报错模式（如先触发
ERROR 1064，再触发ERROR 1146），这是报错注入典型痕迹
最易被忽略的是“信任传递”：把数据库当安全终点，却忘了它只是中间站。只要数据离开受控上下文（比如进到 shell 脚本、Python exec()、JavaScript eval()），之前所有防护就归零。防御演化的关键，不是加更多规则，而是收缩可执行上下文的半径。
