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