白名单更难被绕过，因其默认拒绝一切、仅放行明确允许的输入；而黑名单默认放行、仅拦截已知危险模式，易因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 <code>table_name，白名单无法覆盖所有业务表 - 复杂表达式：比如搜索条件支持
price > 100 AND status = 'active'，白名单很难安全解析语义 - 输入本身合法但组合后危险：如
admin' --是合法用户名，但拼进WHERE username = '<code>admin' -- '' 就导致注释绕过
所以生产环境必须配合参数化查询（PreparedStatement 或 ORM 的 query binding），白名单只是第一道过滤，不是唯一防线。
数据库层白名单机制（如 KingbaseES SQL 防火墙）的特殊价值
应用层白名单管的是“输入值”，而数据库内生白名单管的是“最终执行的 SQL 模板”：
- 学习阶段自动采集
SELECT * FROM users WHERE id = ?这类结构，不记录具体参数值 - 防护阶段只允许该模板的实例（如
id = 123、id = 456）通过，id = 123 OR 1=1直接报错 - 绕不开应用层漏洞：即使开发忘了参数化，只要 SQL 结构不在白名单里，数据库就拒绝执行
这种机制真正实现了“兜底”，但代价是必须先跑完完整业务流程来采集样本，且表结构变更后需重新学习——容易被忽略的点是：学习阶段日志量大，没做采样或归档策略可能导致磁盘打满。
