为何数据迁移脚本也需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 语句本身除非调试需要，否则不记录。