字段名不能参数化，因数据库预编译机制仅支持值绑定，不支持标识符（如列名、表名、排序方向）绑定；必须通过硬编码白名单严格校验，精确匹配允许字段，同时校验ASC/DESC方向，二者缺一不可。
字段名（如 username、created_at）不能像值那样用参数化查询处理——数据库驱动不支持对列名、表名、排序方向等结构化标识符做参数绑定。强行拼接字段名是高危行为，必须用白名单校验兜底。
为什么不能对字段名用 ? 或 %s 占位
SQL 预编译机制只允许参数化 **值（value）**，不允许参数化 **标识符（identifier）**。尝试这么做会直接报错：
psycopg2.errors.SyntaxError: syntax error at or near "$1"
或 Java 中抛出 PSQLException: ERROR: syntax error at or near "$1"。数据库在解析阶段就需要知道表结构和字段名，无法延迟绑定。
字段名拼接的唯一安全方式：严格白名单校验
所有可能被动态使用的字段名，必须提前定义在代码中、硬编码为有限集合，并通过字符串比对确认输入是否合法。不能依赖正则过滤或黑名单。
- 错误做法：用
re.match(r'^[a-zA-Z_][a-zA-Z0-9_]*$', field_name)—— 无法阻止user_id; DROP TABLE users这类绕过（虽然分号在标识符里本就非法，但正则不严谨易误判） - 正确做法：显式声明允许字段列表，再做精确匹配
Python 示例：
ALLOWED_FIELDS = {'username', 'email', 'status', 'created_at', 'updated_at'}
if field_name not in ALLOWED_FIELDS:
raise ValueError(f"Invalid field: {field_name}")
sql = f"SELECT * FROM users ORDER BY {field_name} DESC"Java 示例：
Set<String> allowedFields = Set.of("username", "email", "status");
if (!allowedFields.contains(fieldName)) {
throw new IllegalArgumentException("Field not allowed");
}
String sql = "SELECT * FROM users ORDER BY " + fieldName + " DESC";ORM 框架里字段名怎么处理
主流 ORM（如 SQLAlchemy、MyBatis、Hibernate）对字段名的动态使用仍需白名单控制，框架本身不自动校验。
- SQLAlchemy 中
getattr(User, field_name)会抛出AttributeError如果字段不存在，但不防恶意字段名（如构造假属性触发逻辑漏洞） - MyBatis 的
${}是字符串替换，极度危险；必须配合<bind>或 Java 层白名单拦截 - Hibernate Criteria API 安全，因字段名来自实体类反射，但若字段名来自用户输入再反射，则仍需先校验是否属于该实体的已知属性
排序方向（ASC/DESC）也得校验
排序关键字不是值，也不能参数化。常见错误是直接拼接 ORDER BY name {direction}，而 direction 来自 URL 参数（如 ?sort=desc）。
- 允许值只能是
"ASC"或"DESC"，且必须全大写比对（避免大小写绕过） - 不要用
direction.lower() in ['asc', 'desc']，因为ASC和asc在 SQL 中都合法，但校验逻辑应统一强制规范 - 更稳妥：映射关系，如
{"asc": "ASC", "desc": "DESC"}.get(user_input, "ASC")
拼接时仍需确保字段名和方向都通过独立白名单验证，二者缺一不可。
字段名、表名、排序方向、GROUP BY 字段——这些结构性元素一旦放开拼接，就等于把数据库元信息的控制权交到攻击者手上。白名单不是“加个保险”，而是唯一可行路径。漏掉一个合法字段名，比多写十行转义逻辑更致命。
