一旦确认是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,))；Ja va 必须用 PreparedStatement，禁用 Statement
• 特别注意 ORM 的“原生查询”陷阱：Django 的 raw()、SQLAlchemy 的 text()、MyBatis 的 $ 符号拼接（应改用 #）——这些地方照样会注入

真正难的不是写对那行 prepareStatement，而是让所有开发人员理解：用户输入永远不能出现在 SQL 字符串里，哪怕只加一个单引号。只要还有人觉得“这个字段只输数字，没问题”，风险就还在。

《夸克》非常好用的免费AI浏览器

下载APP查看