唯一有效防线是严格限制应用账号对mysql系统库的权限。攻击者获权后可直接增删改系统表，添加高权限账号、开放GRANT OPTION、清除审计痕迹，且参数化查询无法防御。必须用REVOKE收回mysql.*权限，仅授予业务必需权限，并确保运维与应用账号物理隔离。
直接用 mysql 系统库权限控制，别让应用账号能读写 mysql.user、mysql.db、mysql.tables_priv 这类表——这是唯一有效防线。其他所有“过滤”“转义”“WAF 拦截 SQL 关键字”，对系统表注入完全无效。
为什么系统表注入比普通注入更危险？
普通 SQL 注入最多查数据、删表；但一旦攻击者拿到对 mysql 库的写权限，就能：
- 直接
INSERT INTO mysql.user添加高权限账号，持久化后门 -
UPDATE mysql.db开放某个数据库的GRANT OPTION，再给自己授全权 -
DELETE FROM mysql.proxies_priv清理审计痕迹，或篡改mysql.columns_priv隐藏字段访问记录
这些操作不依赖用户输入拼接，而是靠已有 SQL 执行权 + 账号权限组合达成。只要账号有 INSERT/UPDATE 权限，哪怕你代码 100% 用了 ? 占位符，照样中招。
检查并收紧 MySQL 账号权限的实操步骤
别信“开发环境用 root，上线再改”这种话——线上出事就是现在。
- 用
SHOW GRANTS FOR 'app_user'@'%';查当前账号真实权限，重点看输出里有没有GRANT OPTION、CREATE USER、RELOAD、FILE、PROCESS，以及对mysql.*的任何SELECT/INSERT/UPDATE权限 - 立刻执行
REVOKE ALL PRIVILEGES ON mysql.* FROM 'app_user'@'%';（注意：不是DROP，是REVOKE） - 只授业务必需权限：
GRANT SELECT, INSERT, UPDATE, DELETE ON myapp_db.* TO 'app_user'@'%'; - 确认生效：
FLUSH PRIVILEGES;
如果业务真需要动态建表（极少见），单独开一个运维账号，和应用账号物理隔离，绝不混用。
应用层无法补救系统表权限漏洞
有人试图在 Node.js 里拦截含 mysql. 的 SQL 字符串，或用 ORM 的白名单过滤表名——这全是幻觉。
-
connection.query('UPDATE mysql.user SET authentication_string = ? WHERE User = ?', [...])只要账号有权限，参数化查询照常执行 - ORM 的
raw()、Query Builder 的selectRaw()、甚至 Django 的extra()，都可能绕过框架校验直连系统表 - MySQL 的
sql_mode=STRICT_TRANS_TABLES对权限操作无约束力，它只管数据一致性
真正有效的防护只有两条：账号权限最小化 + 禁止应用账号碰 mysql 库。其他都是障眼法。
最容易被忽略的点：很多团队花大力气审计应用 SQL 拼接，却从不检查部署时创建的数据库账号权限——等发现 mysql.user 被篡改，往往已经失陷数月。
