确认SQL注入导致数据泄露后，首要任务是控制影响范围、评估泄露内容、切断攻击路径，而非立即写补丁；需查审计日志或应用日志定位被查询的高敏表与字段，及时限制数据库账号权限，并全面修复所有SQL拼接点，统一使用参数化查询。
数据已经泄露，再谈“预防”就晚了。当确认发生 SQL 注入导致的数据泄露，第一要务不是写补丁，而是控制影响范围、评估泄露内容、切断攻击路径。
确认泄露范围和敏感字段
很多团队一发现注入点就急着修代码，却没搞清到底哪些表、哪些字段被读取过。攻击者可能用 UNION SELECT 拉走了 users 表的 password_hash 和 email，也可能只是查了 product 表的公开价格——风险等级完全不同。
- 立即查数据库审计日志（如 MySQL 的
general_log或slow_query_log，前提是开启）；没有日志？翻应用层访问日志，找含' OR '1'='1、UNION SELECT、information_schema等关键词的请求 - 重点筛查被查询过的表：检查
SELECT语句中是否出现users、customer、order、payment等高敏表名 - 注意列名推断痕迹：比如 URL 中出现
id=1 UNION SELECT 1,2,3,4,5--，说明攻击者正在试探列数；后续若出现UNION SELECT username,password,email,phone,created_at，基本可判定这些字段已外泄
立刻停用或限制受影响账户权限
注入能跑通，说明应用连接数据库用的账号权限过大。不改权限，修完代码也白搭——新漏洞还没挖，旧账号就能继续读全库。
- 登录数据库，执行
SHOW GRANTS FOR 'app_user'@'%'，确认当前账号是否有SELECT以外的权限（尤其是DROP、INSERT、UPDATE、FILE） - 立刻执行
REVOKE DROP ON *.* FROM 'app_user'@'%'等非必要权限；生产环境原则上只应保留SELECT、INSERT、UPDATE、DELETE在指定库内（如GRANT SELECT,INSERT,UPDATE,DELETE ON myapp.* TO 'app_user'@'%'） - 如果该账号还被用于其他服务，考虑新建专用账号，避免“一账通吃”
修复注入点时别只改一处
一个 WHERE id = ${id} 漏洞被修了，不代表其他地方安全。SQL 注入从来不是孤立 bug，而是编码习惯问题。
- 全局搜索所有拼接 SQL 的位置：grep -r "\.query(" ./src | grep -E "(\"|')\$\{|\+ ?\""，重点关注
mysql.query、pg.query、db.execute等调用 - 强制替换为参数化形式：Node.js 用
pool.query('SELECT * FROM users WHERE id = $1', [id])；Python 用cursor.execute("SELECT * FROM users WHERE id = %s", (id,))；Java 必须用PreparedStatement，禁用Statement - 特别注意 ORM 的“原生查询”陷阱：Django 的
raw()、SQLAlchemy 的text()、MyBatis 的$符号拼接（应改用#）——这些地方照样会注入
真正难的不是写对那行 prepareStatement，而是让所有开发人员理解：用户输入永远不能出现在 SQL 字符串里，哪怕只加一个单引号。只要还有人觉得“这个字段只输数字，没问题”，风险就还在。
