表名和字段名动态拼接时的 SQL 注入防御

在 Web 安全领域，SQL 注入始终是 OWASP Top 10 中的常客。大多数开发者对参数化查询已经耳熟能详，知道用户输入应该通过占位符传递，而不是拼接进 SQL 语句。然而，当动态拼接的对象从“值”变成“表名”或“字段名”时，很多人会突然发现：占位符不管用了。

这是一个真实存在且极易被忽视的盲区。本文将从实际场景出发，分析表名和字段名动态拼接带来的注入风险，并给出可落地的防御方案。

为什么表名和字段名不能用参数化查询

参数化查询的原理是：SQL 语句的结构（表名、字段名、关键字）在预编译阶段就已经确定，数据库只负责将参数值填入对应的位置。换句话说，占位符只能替代“值”，不能替代“标识符”。

以下写法在 MySQL 中会直接报错：

SELECT * FROM ? WHERE id = ?

因为数据库引擎在预编译时无法知道表名是什么，也就无法生成执行计划。这就导致很多开发者在需要动态选择表名或字段名时，被迫回到字符串拼接的老路：

sql = f"SELECT * FROM {table_name} WHERE id = %s"
cursor.execute(sql, (user_id,))

如果 table_name 来自用户输入且未经严格校验，注入就发生了。

动态标识符拼接的真实风险场景

这类需求在实际开发中并不少见，常见的场景包括：

• 多租户系统：根据租户 ID 选择不同的数据表，如 orders_tenant01、orders_tenant02
• 后台管理系统：允许管理员选择排序字段，如 ORDER BY {sort_field} {sort_order}
• 报表系统：用户自定义查询维度，动态选择返回哪些列
• 分表分库中间件：根据路由规则拼接物理表名

这些场景的共同点是：标识符确实需要动态化，但动态化的来源如果包含用户可控输入，就会形成注入点。

以排序功能为例，很多开发者会这样写：

sort_field = request.GET.get('sort', 'created_at')
order = request.GET.get('order', 'desc')
sql = f"SELECT * FROM articles ORDER BY {sort_field} {order}"

攻击者只需传入 sort=id,(SELECT SLEEP(5)) 或更复杂的子查询，就能实现盲注、数据外带甚至写入操作。

防御的核心原则：白名单映射

既然参数化查询无法覆盖标识符，我们就需要另一种思路：不让用户直接决定标识符，而是让用户从一个预定义的白名单中选择。

方案一：映射表（推荐）

最安全的做法是建立“用户输入 → 实际标识符”的映射关系。用户传入的是逻辑名称，代码内部转换为真实的表名或字段名。

SORT_FIELD_MAP = {
    'created': 'created_at',
    'updated': 'updated_at',
    'title': 'title',
    'views': 'view_count',
}

sort_key = request.GET.get('sort', 'created')
if sort_key not in SORT_FIELD_MAP:
    sort_key = 'created'
sort_field = SORT_FIELD_MAP[sort_key]

ORDER_MAP = {'asc': 'ASC', 'desc': 'DESC'}
order = ORDER_MAP.get(request.GET.get('order', 'desc'), 'DESC')

sql = f"SELECT * FROM articles ORDER BY {sort_field} {order}"

这样做的好处是：即使映射表被意外暴露，攻击者也只能看到有限的几个字段名，无法注入任意 SQL 片段。

方案二：严格的正则校验

如果业务确实需要较高的灵活性，无法穷举所有字段名，可以使用严格的正则表达式进行校验。标识符的合法字符集通常非常有限：

import re

def validate_identifier(name):
    if not re.match(r'^[a-zA-Z_][a-zA-Z0-9_]{0,63}$', name):
        raise ValueError('Invalid identifier')
    return name

table_name = validate_identifier(request.GET.get('table'))

这个正则要求标识符必须以字母或下划线开头，只包含字母、数字和下划线，长度不超过 64 个字符。它排除了空格、引号、括号、分号、注释符等所有可能用于注入的字符。

需要注意的是，正则校验必须使用 ^...$ 锚定整个字符串，否则攻击者可以在合法字符后面追加恶意内容。

方案三：使用数据库驱动的引用函数

某些数据库驱动提供了标识符引用的方法，例如 PostgreSQL 的 psycopg2.sql.Identifier：

from psycopg2 import sql

query = sql.SQL("SELECT * FROM {table} WHERE id = %s").format(
    table=sql.Identifier(table_name)
)
cursor.execute(query, (user_id,))

sql.Identifier 会自动为标识符加上双引号并转义内部的双引号，从而防止注入。但前提是 table_name 本身仍然需要经过白名单或正则校验——引用函数解决的是“特殊字符转义”问题，不是“用户输入是否合法”的问题。

常见误区与注意事项

误区一：用反引号包裹就安全了。 在 MySQL 中，反引号包裹的标识符如果内部包含反引号，仍然可以被闭合。攻击者输入 `; DROP TABLE users; -- 时，简单的反引号包裹并不能阻止注入。

误区二：过滤了关键字就安全了。 黑名单过滤（如过滤 SELECT、UNION、DROP）永远滞后于攻击手法，大小写混写、注释插入、编码绕过等方式可以轻松突破。

误区三：只校验一次就够了。 如果标识符在多个层级之间传递（如从 Controller 传到 Service 再到 DAO），每一层都应该假设输入不可信，或者在入口处完成校验后以安全类型传递。

注意事项： 动态拼接的 SQL 语句应该记录到日志中，但日志中不应包含完整的用户输入原文，以免日志注入。同时，数据库账户应遵循最小权限原则，Web 应用使用的账户不应有 DROP、ALTER 等 DDL 权限。

总结

表名和字段名的动态拼接是 SQL 注入防御中的一个特殊场景，参数化查询在此无能为力。防御的核心思路是：永远不要让用户输入直接成为 SQL 标识符。优先使用白名单映射，其次使用严格的正则校验，必要时结合数据库驱动的标识符引用函数。三层防御叠加，才能在这个容易被忽视的角落里堵住注入的缺口。

安全从来不是某一个措施就能解决的问题，而是需要在每一个细节上保持警惕。当你下次准备用 f-string 拼接表名时，不妨先停下来问自己一句：这个表名，真的可信吗？

未经允许不得转载：任鹏个人博客 » 表名和字段名动态拼接时的 SQL 注入防御