白名单防御模式拦截SQL注入为何比黑名单模式更可靠？

白名单为何比黑名单更难被绕过

白名单的防御逻辑是：默认拒绝所有输入，只放行那些明确允许的字段或字符。黑名单则相反，默认放行一切，仅拦截已知的威胁模式。SQL注入的变体数量极多——大小写混用、URL编码、注释符嵌套（例如将 ' OR 1=1-- 变为 '%20OR%201%3D1%23），以及空格被替换为 %09 或 /**/——黑名单规则只要稍有遗漏或匹配不严，攻击者就能乘虚而入。

白名单在实际输入校验中如何落地

白名单的落地并非简单列一个允许字符列表，而是需要紧密结合业务语义：

• user_id 字段：只允许 ^d+$（纯数字），连负号、小数点、前导零都直接拒绝。
• username 字段：限定长度并采用 ^[a-zA-Z0-9_]{3,20}$，拒绝单引号、分号、括号、反斜杠等特殊字符。
• sort_by 字段（用于动态排序）：不能直接拼接用户输入，而应映射到预定义的枚举值。例如，构建一个 {'name': 'user_name', 'time': 'created_at'} 字典，从其中取出对应的字段名。

关键点在于：白名单规则必须与具体业务逻辑强绑定。脱离上下文的“通用白名单”（如只允许字母和数字）反而可能误杀合法输入，例如邮箱中的 @、中文用户名等。

为何光靠白名单仍不够

白名单能拦截大部分非法输入，但无法解决所有问题，尤其有三类典型场景是其力所不能及的：

• 动态表名/字段名：例如SQL中拼接 SELECT * FROM table_name，白名单无法覆盖所有业务表。
• 复杂表达式：某些搜索条件支持 price > 100 AND status = 'active'，白名单难以安全解析这类语义。
• 输入本身合法但组合后危险：例如 admin' -- 本身是一个合法用户名，但拼接到 WHERE username = 'admin' -- ' 中会导致注释绕过。

因此，在生产环境中，必须将参数化查询（PreparedStatement 或 ORM 的查询绑定）作为核心防线，白名单只是第一道过滤，并非唯一屏障。

数据库层白名单机制（如 KingbaseES SQL 防火墙）的特殊价值

应用层的白名单管控的是“输入值”，而数据库内生的白名单管控的是“最终要执行的SQL模板”，这属于两个不同层面：

• 学习阶段自动采集 SELECT * FROM users WHERE id = 这样的结构，不记录具体参数值。
• 防护阶段只允许该模板的实例（如 id = 123、id = 456）通过，id = 123 OR 1=1 这类语句直接报错。
• 它能绕开应用层漏洞：即使开发人员忘记使用参数化，只要SQL结构不在白名单内，数据库就会拒绝执行。

这种机制实现了真正的“兜底”，但代价是必须先跑完完整的业务流程来采集样本，且表结构变更后需要重新学习。一个容易被忽略的点是：学习阶段的日志量非常大，若未做采样或归档策略，磁盘可能被写满。