高级SQL注入需用AST解析与语义策略过滤，因WHERE 1=1、UNION SELECT等静态规则易被注释、编码、大小写、数据库特性绕过，且无法识别合法语法下的非法意图。
高级SQL注入攻击无法靠简单关键词黑名单防住，必须在应用层或网关层引入基于语义和执行策略的请求过滤机制。
为什么 WHERE 1=1 和 UNION SELECT 这类规则会失效
现代SQL注入常绕过静态字符串匹配：用注释符分隔（/**/）、编码混淆（%20、%0a）、大小写混用（UnIoN）、甚至利用数据库特性（如MySQL的/*+ … */优化提示）伪装成合法查询。单纯匹配关键字或正则替换会漏掉嵌套子查询、动态拼接的CTE、或通过EXECUTE IMMEDIATE间接触发的注入。
实操建议：
- 停用所有基于
SELECT|INSERT|UNION|;|/*的纯文本拦截规则，它们对SELECT * FROM users WHERE id = ? AND (SELECT COUNT(*) FROM information_schema.tables) > 0这类“合法语法+非法意图”的请求完全无效 - 改用能解析SQL AST（抽象语法树）的过滤器，例如使用
sqlparse（Python）或js-sql-parser（Node.js）做结构校验，而非字符串扫描 - 对参数化查询中的占位符（如
?、:name）强制绑定类型，拒绝传入非预期类型值（例如id字段绑定字符串'1 OR 1=1'时直接报错）
PreparedStatement 不等于绝对安全：参数绑定的常见误用
很多团队以为用了PreparedStatement就高枕无忧，但实际中仍频繁出现漏洞，根源在于“伪参数化”——即把用户输入拼进SQL字符串后再交给预编译，或在非参数位置（如表名、排序字段、LIMIT偏移量）使用变量插值。
实操建议：
- 检查所有
executeQuery()、executeUpdate()调用前的SQL字符串：若其中包含+、format()、f-string或模板引擎插值，立即重构 - 数据库对象名（表、列、索引）必须来自白名单枚举，不可由用户输入映射，例如：
if not user_sort_field in ['created_at', 'score']: raise ValueError - 对
LIMIT和OFFSET参数，强制转为整型并加范围限制（如max(0, min(int(user_limit), 100))），防止注入LIMIT 10, (SELECT ...)
基于策略的过滤：如何定义和加载可执行的SQL策略
策略不是配置开关，而是可评估的规则函数。它需要结合上下文判断：当前用户角色、目标表敏感度、SQL操作类型、是否含子查询、是否存在跨schema引用等。
实操建议：
- 定义策略时避免布尔开关（如
allow_union=true），改用表达式，例如：not contains_subquery(sql_ast) or (user.role == 'dba' and count_subqueries(sql_ast) - 策略应与权限系统联动：普通用户查询
users表允许WHERE，但禁止JOIN logs；管理员可查logs，但禁止ORDER BY (SELECT ...) - 在API网关（如Kong、APISIX）或ORM中间件中注入策略引擎，优先在
before_execute钩子中解析SQL并调用策略函数，拒绝则返回400 Bad Request并记录sql_policy_violation事件
真正难处理的是那些不报错、不回显、也不改变响应体结构的盲注场景——比如基于时间延迟的SLEEP()或布尔逻辑翻转。这类攻击不会触发传统WAF告警，必须依赖SQL解析器识别非常规函数调用，并结合数据库审计日志做行为基线比对。策略过滤不是银弹，但它能把防御点从“拦不住就完蛋”推进到“能感知、可追溯、可收敛”。
