数据迁移脚本中为何也要考虑SQL注入防御？

数据迁移脚本虽然不像Web接口那样直接面向终端用户，但其潜在风险同样不容忽视——只要脚本拼接了未经验证的外部输入，例如配置文件中的参数、命令行参数、CSV文件中的字段值，甚至是环境变量，就依然存在被注入攻击的可能。正确的防御策略是：将SQL结构与数据严格分离，表名和列名必须通过白名单校验机制，错误日志也需进行脱敏处理。

或许你会认为迁移脚本属于内部工具，不易遭受攻击。然而现实情况是，攻击者只要获取到低权限账号（例如Jenkins构建账号），便能够通过污染配置信息间接操控迁移逻辑。因此，切莫以为“仅在内网运行”就能高枕无忧。

迁移脚本中哪些环节会拼接 SQL？

常见的风险点远不止在 INSERT INTO 语句中直接拼接数据那么简单：

• 利用 sys.argv 或 os.environ 读取表名、库名以及 WHERE 条件（例如 --target-table users_2024）
• 从 CSV 或 Excel 文件中提取字段值后，未经类型校验或引号转义便直接插入到 VALUES (...) 中
• 依据配置文件生成动态 CREATE TABLE 语句，其中表名或列名直接来源于 JSON 配置项
• 执行 mysqldump 或 pg_dump 后，通过 shell 脚本拼接 mysql -e "USE $DB_NAME; SOURCE ..." 命令

这些输入源虽然不同于用户提交的表单数据，但同样不可轻信。一旦攻击者能够控制部署环境变量或篡改迁移配置文件，就完全有可能触发注入攻击。

为什么不能仅凭“脚本只在内网运行”来推卸责任？

内网环境绝不等于绝对安全。实际运维中容易踩中的陷阱包括：

• docker run -e DB_NAME='test; DROP TABLE users; --' —— 环境变量未经清理就直接用于 SQL 拼接
• 在 CI/CD 流水线中，分支名或标签名被直接用作数据库后缀（例如 prod_v2 对应 users_prod_v2），而分支名往往可由 PR 提交者控制
• 运维人员手动执行迁移时，复制粘贴的命令中可能包含隐藏字符或换行符，导致语句意外截断或注释失效

一旦攻击者获得低权限账号（比如 Jenkins 构建账号），就能通过污染配置来间接操控迁移逻辑的执行流程。

如何编写安全的迁移脚本？优先采用参数化查询，杜绝字符串拼接

不同语言编写的迁移脚本具体实现各异，但核心原则始终如一：SQL 结构与数据必须彻底分离。

• Python + psycopg2：使用 cursor.execute("SELECT * FROM %s WHERE id = %s", (table_name, user_id)) ❌ 这是错误的——%s 占位符不能用于表名；正确的做法是先对 table_name 进行白名单校验，再通过 sql.SQL("SELECT * FROM {}").format(sql.Identifier(table_name)) 来构建查询
• Bash + mysql：避免使用 mysql -e "INSERT INTO $TABLE ..." 这种拼接方式；推荐改用 mysql --defaults-file=cred.cnf -e "INSERT INTO users VALUES (?, ?)"，并配合 mysqlimport 或 LOAD DATA INFILE（需确保文件路径可控）
• Go + database/sql：所有用户输入都必须通过 db.Query("SELECT * FROM users WHERE name = ?", name) 方式处理，绝对避免使用 fmt.Sprintf 来拼接 SQL 语句

对于表名、列名等无法参数化的结构部分，必须严格执行白名单校验或正则表达式验证（例如 ^[a-zA-Z][a-zA-Z0-9_]{1,63}$），同时拒绝任何包含点号、美元符、分号或反引号的输入内容。

最容易被忽视的细节：错误信息与日志记录

迁移操作失败时，切勿将原始 SQL 语句和数据库报错信息原封不动地输出到 stdout 或日志文件中。否则可能带来以下风险：

• 报错内容可能泄露表结构信息（例如 Unknown column 'password_hash' in 'field list'）
• 攻击者可以通过构造异常输入，观察系统响应差异来探测字段名称或业务逻辑
• 日志文件若未做脱敏处理，一旦泄露就等于为攻击者留下了清晰的攻击痕迹地图

真正应该记录的日志内容包括：操作人员、操作时间、目标数据库、影响行数以及是否执行了回滚操作；除非出于调试需要，否则 SQL 语句本身不应记录在日志中。