为什么在数据迁移脚本中也需要防御SQL注入

数据迁移脚本存在SQL注入风险，因其常拼接不可信输入（如环境变量、配置文件、CSV字段等）；应严格分离SQL结构与数据，表名列名须白名单校验，错误日志需脱敏。

数据迁移脚本不是生产接口，但照样可能被注入——只要它拼接了未经验证的外部输入（比如配置文件、命令行参数、CSV字段、环境变量），就存在风险。

迁移脚本里哪些地方会拼接 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 语句本身除非调试需要，否则不记录。