白名单是唯一能从语法结构层面切断 ORDER BY 注入链的手段，必须按业务语义显式枚举字段名与排序方向，并与接口权限、数据分级强绑定。
因为 ORDER BY 后的字段名和排序方向根本不能参数化，白名单是唯一能从语法结构层面切断注入链的手段。
ORDER BY 字段无法用 ? 或 :param 占位符
MySQL、PostgreSQL 等主流数据库在解析 SQL 时，ORDER BY 后必须是标识符（identifier），不是表达式或值。你写 SELECT * FROM user ORDER BY ?，驱动不会报错，但实际效果是按字面量 ? 这个字符串排序——它被当成一个固定列名，而非参数。这意味着：任何“用了占位符就安全”的假设，在 ORDER BY 场景下都是错觉。
- MyBatis-Plus 的
orderByAsc(String column)是字符串拼接，不是预编译 - SQLAlchemy 的
order_by(text(f'{field} {dir}'))仍是裸拼，ORM 不管键名 - PHP 的
$query->addOrderBy([$sort => $dir])只绑定值，不校验键名
正则/转义/黑名单为什么都不可靠
这些方案都在“清洗输入”，但攻击者根本不需要触发单引号或分号——他们只要让数据库把恶意内容当成合法标识符解析就行。
- 正则
^[a-zA-Z_][a-zA-Z0-9_]*$挡不住id%00; DROP TABLE--，因为 %00 是空字符，部分解析器会截断后续 - 过滤
UNION、SELECT关键字？攻击者用id ASC, (SELECT password FROM user LIMIT 1)直接绕过 -
mysql_real_escape_string对字段名完全无效——它只转义字符串字面量里的引号，而ORDER BY id根本没引号
真正有效的白名单长什么样
白名单不是“允许字母数字下划线”，而是按业务语义显式枚举、强制映射、严格比对。
- 字段名必须来自封闭集合：
['id', 'created_at', 'title', 'status']，不在其中一律拒绝或 fallback 到默认值 - 排序方向必须单独校验：
if order_dir.lower() not in ['asc', 'desc'] → raise ValueError - 推荐用映射表避免硬编码拼接：
sort_map = {'name': 'user_name', 'time': 'created_at'}，再取sort_map.get(user_input, 'id') - Django 中用
getattr(User, field_name)获取字段对象传给.order_by()，比直接拼字符串安全得多
容易被忽略的权限与上下文问题
一个字段名在白名单里，不代表当前用户有权按它排序——比如后台可按 email 排，但用户端接口就不该出现在白名单中；更进一步，按 salary 排序本身可能泄露敏感信息，即使字段名合法。
白名单必须和接口权限、字段可见性、数据分级强绑定，脱离业务上下文的“通用白名单”等于形同虚设。
