如何通过MySQL系统表直接分析当前潜伏的高危权限账号？-mysql教程-PHP中文网

super_priv和grant_priv是关键指标，因前者可kill线程、修改全局变量、写binlog，后者能任意授/回收权限，任一为y即具备横向提权能力；需结合mysql.role_edges和mysql.proxies_priv交叉验证，避免仅依赖show grants遗漏角色继承与代理权限。

如何通过mysql系统表直接分析当前潜伏的高危权限账号？

查 `mysql.user` 表时为什么 `Super_priv` 和 `Grant_priv` 是关键指标？这两个字段直接决定账号能否绕过权限系统做破坏性操作。`Super_priv` 允许 kill 线程、修改全局变量、写入 binlog；`Grant_priv` 则能任意授予/回收他人权限——两者任一为 `Y`，该账号就具备横向提权能力。常见误判是只看 `SELECT`/`INSERT` 权限，但高危账号往往权限“看起来很干净”，实则靠这两项暗度陈仓。注意：MySQL 8.0+ 中部分权限已迁移到 `mysql.role_edges` 和 `mysql.proxies_priv`，但 `Super_priv` 和 `Grant_priv` 仍在 `mysql.user` 中保留且生效。

执行以下语句快速定位：

SELECT host, user, Super_priv, Grant_priv, authentication_string 
FROM mysql.user 
WHERE Super_priv = 'Y' OR Grant_priv = 'Y';

为什么不能只依赖 `SHOW GRANTS`？ `SHOW GRANTS FOR 'user'@'host'` 只显示显式授予的权限，不反映角色继承、代理权限（`PROXY`）、或通过 `SET DEFAULT ROLE` 激活的隐式权限。更隐蔽的是：MySQL 5.7+ 支持 `CREATE USER` 时不赋任何权限，但若该用户被加入拥有 `GRANT OPTION` 的角色，它就能间接获得高危能力。所以必须交叉验证：`mysql.user` + `mysql.role_edges` + `mysql.default_roles`。

检查角色继承链：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

SELECT r.from_host, r.from_user, r.to_host, r.to_user, u.Super_priv, u.Grant_priv
FROM mysql.role_edges r
JOIN mysql.user u ON r.to_host = u.host AND r.to_user = u.user
WHERE u.Super_priv = 'Y' OR u.Grant_priv = 'Y';

`mysql.proxies_priv` 表里的 `Grant_priv` 字段意味着什么？这个表控制代理权限（proxy privileges），即“A 用户可冒充 B 用户执行操作”。如果某行的 `Grant_priv` 为 `Y`，说明代理者不仅能以被代理者身份登录，还能代其执行 `GRANT` ——等效于双重高危权限。典型风险场景：运维账号 `'dba'@'%'` 被设为 `'app'@'10.0.1.%'` 的 proxy，并开了 `Grant_priv`，那么应用服务器上的任意数据库连接都可能升级为权限提升入口。该表默认只在启用 `check_proxy_users` 且配置了代理关系时才有数据，但一旦存在，就必须纳入扫描范围。

检查代理高危配置：

SELECT Host, User, Proxied_host, Proxied_user, Grant_priv 
FROM mysql.proxies_priv 
WHERE Grant_priv = 'Y';

为什么 `authentication_string` 为空或为 `` 的账号要重点盯防？空密码（`authentication_string = ''`）或弱哈希（如 MySQL 5.6 的 `` 开头旧格式）本身不是权限问题，但会极大降低攻击门槛。一旦网络层暴露（比如意外绑定到公网、跳板机未加固），这类账号就是最短路径的突破口。尤其要注意：MySQL 8.0 默认使用 `caching_sha2_password`，若 `authentication_string` 显示为 `*`，大概率是旧版本迁移残留，且密码未重置——此时即使权限不高，也极可能成为跳板。不要仅凭 `plugin` 字段判断安全性，必须结合 `authentication_string` 内容和实际密码强度交叉验证。

快速筛出可疑认证状态：

SELECT host, user, plugin, authentication_string 
FROM mysql.user 
WHERE authentication_string = '' 
   OR authentication_string LIKE '*%';

权限分析真正难的不是查表，而是理解哪些组合会在特定部署拓扑下形成隐式提权通路——比如一个只有 SELECT 权限的账号，若同时在 proxies_priv 中被授权代理高权限账号，它就不再是“只读”账号。