SQL注入应急三件事：第一隔离风险，立即断开应用与数据库连接并禁用被攻破账号；第二反向追踪，通过PROCESSLIST或pg_stat_activity定位异常会话；第三彻底撤销权限，注意角色继承和级联问题，同时终止活跃会话。
发现SQL注入后立刻要做的三件事
不是先查日志，也不是马上写补丁——第一反应必须是隔离风险。SQL注入已经发生，说明攻击者可能已拿到数据库连接权限，甚至执行了SELECT、UNION或INTO OUTFILE等高危操作。
- 立即断开应用服务器与数据库的连接（比如重启应用服务，或临时修改数据库连接池配置中的
url指向无效地址） - 在数据库侧禁用被攻破的账号：对MySQL执行
REVOKE ALL PRIVILEGES ON *.* FROM 'app_user'@'%'; FLUSH PRIVILEGES;；对PostgreSQL执行REVOKE ALL ON DATABASE mydb FROM app_user;并ALTER ROLE app_user NOLOGIN; - 检查该账号是否拥有
superuser（PostgreSQL）或FILE、PROCESS、GRANT OPTION（MySQL）等危险权限——有则优先撤掉，别等“后续再处理”
如何快速定位哪个账号被滥用
靠日志太慢，靠人工翻代码容易漏。关键是用数据库自身的会话和权限视图反向追踪。
- MySQL：查
information_schema.PROCESSLIST中长时间运行、来源IP异常、SQL含UNION SELECT或sleep(的连接；再用SHOW GRANTS FOR 'x'@'y';确认权限范围 - PostgreSQL：查
pg_stat_activity里state = 'active'且query字段含UNION、pg_sleep、COPY的记录；用\du+或SELECT rolname, rolsuper, rolcanlogin FROM pg_roles WHERE rolname = 'app_user';验证角色属性 - 注意：很多应急场景下
general_log或log_statement没开，此时PROCESSLIST/pg_stat_activity是唯一实时线索，别指望审计日志
撤销权限时最容易错的两个地方
不是所有REVOKE都生效，也不是撤完就安全了。
- MySQL中，如果账号通过角色（如
CREATE ROLE r1; GRANT SELECT ON db.* TO r1;）间接获得权限，只对用户REVOKE不生效，必须先REVOKE r1 FROM 'app_user'@'%';再撤角色本身 - PostgreSQL中，
REVOKE默认不级联，若app_user把权限转授给了report_user，直接REVOKE不会影响后者——得加CASCADE参数，否则攻击面还在 - 权限撤销后，已有连接不会自动断开，MySQL需
KILL [ID]，PostgreSQL需SELECT pg_terminate_backend(pid)，漏掉这点等于白撤
为什么不能只改密码或删账号
改密码治标不治本，删账号可能引发应用雪崩。
- 攻击者可能已导出敏感数据，或已写入webshell到数据库（如MySQL的
SELECT ... INTO OUTFILE），此时重点是止损，不是掩盖痕迹 - 直接
DROP USER会导致应用报Access denied for user或连接池持续重试，可能触发下游告警风暴；应先NOLOGIN或REVOKE，留出排查窗口 - 有些中间件（如ShardingSphere、MyCat）缓存了用户权限，单纯数据库侧操作后需手动刷新或重启代理层，否则权限变更不生效
事情说清了就结束。最常被忽略的是：权限撤销后未终止活跃会话，以及没检查角色继承链——这两点会让应急动作形同虚设。
