白名单机制无法防御复杂动态SQL注入，因其仅适用于结构可控的SQL；动态表名、列名、ORDER BY字段或UNION子句会使指纹匹配失效，须结合参数化查询与二级白名单校验。
白名单机制本身不能直接防御复杂动态SQL注入——它只对“结构可控”的SQL有效；一旦出现动态表名、列名、ORDER BY字段或UNION子句，白名单就失效了，必须配合其他手段。
白名单为什么在动态SQL场景下会失效
白名单校验依赖SQL指纹（如AST归一化后的结构），但动态SQL的本质是结构本身由用户输入决定。比如：SELECT * FROM ? WHERE ? = ? ORDER BY ? 中的四个 ? 分别代表表名、列名、值、排序字段——这些位置无法用参数化占位符替代，而白名单系统在提取指纹时，若发现 tables 或 order_by 字段含变量，就无法匹配预存模板。
常见失效现象包括：
- 请求带
?sort=created_at DESC，后端拼成ORDER BY created_at DESC→ 白名单中无此完整结构，拦截或放行都不可靠 - 前端传
table=logs_202609，后端拼成SELECT * FROM logs_202609→ 表名变化导致指纹哈希完全不同 - 使用
UNION SELECT version(), database()绕过单语句白名单 → 白名单通常只校验首条语句
动态标识符（表名/列名）必须走独立白名单校验
参数化查询保护的是值，不是标识符。对动态部分，不能靠“过滤关键词”或“正则替换”，而要建立二级白名单：只允许从预定义集合中选取。
实操建议：
- 把合法表名、列名、排序字段预先写死到配置或枚举中，例如：
allowed_tables = ["users", "orders", "products"]，运行时用in_array($table, $allowed_tables)或Enum.valueOf(table)校验 - 避免用字符串拼接生成
ORDER BY子句，改用映射表：$sortMap = ["name" => "username", "time" => "created_at"]，再取$sortMap[$input] - 禁止任何用户输入直接进入
FROM、JOIN、GROUP BY、HAVING等结构性子句 - 如果业务真需要高度动态（如BI报表），应将整个查询逻辑封装为预定义视图或存储过程，用户仅传参数ID
学习模式 + 指纹聚类是上线前必须做的准备动作
直接启用拦截模式会导致大量误杀，尤其对已有系统。白名单不是配置完就生效的，它需要先“看见”真实流量中的合法变体。
正确做法是分两步走：
- 开启学习模式（
learning_mode = true），记录所有执行SQL的AST指纹和原始语句，不拦截，只告警并入库 - 用脚本对指纹做聚类分析，合并语义等价但字面不同的SQL（如
WHERE status IN (1,2)和WHERE status IN (?,?)应归为一类） - 人工审核聚类结果，剔除明显异常项（如含
UNION SELECT的指纹），再批量导入白名单表 - 灰度阶段开启
block_on_mismatch = false，仅记录未命中项，持续观察7天以上再切全量拦截
白名单与参数化查询必须共存，缺一不可
白名单防不住值层面的绕过，参数化防不住结构层面的变异。两者是互补关系，不是替代关系。
典型错误组合：
- 只做白名单，但
WHERE id = $_GET['id']仍用字符串拼接 → 攻击者传id=1 OR 1=1，指纹可能匹配（因WHERE结构未变），但语义已失控 - 只做参数化，但
SELECT * FROM users ORDER BY ?把用户输入当列名传入 → 驱动层直接报错或执行恶意字段 - ORM中混用
queryRawUnsafe和参数化 → 白名单系统根本看不到原始查询，完全失效
真正安全的写法是：结构固定部分走白名单，值部分走参数化，动态标识符走二级白名单校验。这三者边界一旦模糊，防护就形同虚设。
