如何通过phpMyAdmin查找具有最高权限的风险用户_全局权限审计

最准方法是直接查mysql.user表并结合mysql.db、mysql.role_edges等系统表，因phpMyAdmin界面会遗漏GRANT OPTION、角色继承权限及Db='*'等伪全局权限。

怎么看哪些用户有 ALL PRIVILEGES ON *.*

想知道谁手握数据库的“生杀大权”？最直接、最可靠的方法，就是去查 mysql.user 这张核心系统表。在phpMyAdmin里，找到这个库和表，加个简单的筛选条件就能一目了然。这里有个关键提醒：千万别完全相信图形界面“权限”标签页里的汇总信息——它通常只展示那些被显式授予的权限，而像 GRANT OPTION（授权权限）或者通过角色继承来的权限，很容易就被漏掉了。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

具体可以这么操作：

立即学习“PHP免费学习笔记（深入）”；

• 在phpMyAdmin中，进入 mysql 库，打开 user 表，切换到“搜索”页签。将关键权限字段如 Super_priv、Grant_priv、Reload_priv 的值都设为 Y 进行筛选。
• 更稳妥的方式是直接执行SQL查询：

  SELECT User, Host FROM mysql.user WHERE Super_priv = 'Y' OR Grant_priv = 'Y' OR Create_user_priv = 'Y';

• 需要警惕的是：虽然MySQL 8.0+默认禁用了 root@localhost 的远程访问，但如果存在 root@'%' 这样的用户，那就是一个明确的高风险点。

为什么 SHOW GRANTS FOR 'user'@'host' 比界面更可靠

phpMyAdmin的“用户账户”页面确实方便，它会把权限分门别类地展示出来。但问题恰恰出在这里：像 SHUTDOWN、PROCESS 这类全局权限，在图形界面里经常被折叠，或者归类得模糊不清，甚至干脆不显示。相比之下，SHOW GRANTS 命令返回的是MySQL服务器内部实际执行的授权语句，原汁原味，没有任何歧义。

常见的“踩坑”场景包括：

• 界面上看到“所有数据库权限”打了勾，却没注意到是否包含了关键的 WITH GRANT OPTION（允许该用户给他人授权）。
• 用户被赋予了 PROXY 权限（可以冒充其他用户），但界面可能只字不提。
• 在MySQL 8.0+中使用了角色（Roles），界面可能只显示角色名称，而不会展开列出这个角色具体拥有哪些权限。

因此，建议养成这个习惯：

立即学习“PHP免费学习笔记（深入）”；

• 在phpMyAdmin的“SQL”页签里直接运行命令：

  SHOW GRANTS FOR 'admin'@'192.168.%';

• 仔细审视输出结果，重点盯住有没有 ON *.* 和 WITH GRANT OPTION 这些字眼。
• 如果看到 USING 'role_name' 这样的语句，说明权限来自角色，必须进一步查询：

  SELECT * FROM mysql.role_edges WHERE TO_HOST = 'role_name';

mysql.db 和 mysql.tables_priv 里藏着“伪全局权限”

有些用户的权限配置堪称“隐形杀手”。他们明明没有被授予 *.* 这样的全局权限，却实际上能操作所有数据库。秘密就藏在 mysql.db 系统表里：当某个用户的 Host 字段是 %，并且 Db 字段也是通配符 * 时，这就等效于拥有了全局权限。然而，这种配置在phpMyAdmin的用户列表里是完全不体现的。

这种情况通常出现在：

• 从旧版本迁移遗留的权限配置，管理员误以为只给了数据库级权限，实际上却是通配符。
• 脚本自动创建用户时，Db 字段拼写错误，写成了 '*' 而不是类似 'test\_%' 这样的模式。

排查这类隐藏风险，可以这么做：

立即学习“PHP免费学习笔记（深入）”；

• 查询 mysql.db 表：

  SELECT User, Host, Db FROM mysql.db WHERE Db = '*' AND Host != 'localhost';

• 检查 mysql.tables_priv 表中，是否存在 Table_name = '%' 且 Db = '*' 的记录（虽然少见，但确实存在）。
• 值得注意的是，这类通过系统表直接配置的“伪全局权限”，无法用 SHOW GRANTS 命令直接还原查看，必须查询系统表本身。

MySQL 8.0+ 的角色权限容易被 phpMyAdmin 忽略

角色（Roles）是MySQL 8.0引入的强大功能，但早期版本的phpMyAdmin（如4.9及更早）对它的支持相当薄弱。点开用户详情，很可能看不到其激活的角色，更不会递归展示角色所携带的所有权限。这就导致一个现象：一个用户自身的权限看起来平平无奇，但一旦执行了 SET DEFAULT ROLE all_power TO 'dev'@'%';，他就瞬间拥有了全部权限。

这带来的主要影响是：

• 权限检查性能上，角色权限比直接授权略慢，但审计时的核心问题是“看不见”，导致权限评估失真。
• phpMyAdmin 5.0+ 开始支持角色列表，但默认可能未启用；需要确认配置中的 $cfg['Servers'][$i]['AllowRoot'] 和 auth_type 是否允许读取 mysql.role_edges 系统表。

因此，在MySQL 8.0+环境中，审计时必须额外关注角色：

立即学习“PHP免费学习笔记（深入）”；

• 强制检查所有角色分配关系：

  SELECT FROM_USER, FROM_HOST, TO_USER, TO_HOST FROM mysql.role_edges;

• 查询特定用户的默认角色：

  SELECT Default_role FROM mysql.default_roles WHERE USER = 'api' AND HOST = '%';

• 核心建议：在升级到MySQL 8.0之后，切勿再单纯依赖phpMyAdmin的“权限”页签做最终的安全判断。

总结来说，真正的风险往往不在明处的 root，而在于那些权限分散在多张系统表、又混合了角色和通配符的账号——它们在phpMyAdmin的图形界面里最不起眼，却恰恰是安全审计中最容易被遗漏的盲点。