首页 > 数据库 >如何通过phpMyAdmin查找具有最高权限的风险用户_全局权限审计

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

来源:互联网 2026-04-25 15:37:08

最准方法是直接查mysql.user表并结合mysql.db、mysql.role_edges等系统表,因phpMyAdmin界面会遗漏GRANT OPTION、角色继承权限及Db='*'等伪全局权限。 怎么看哪些用户有 ALL PRIVILEGES ON *.* 想知道谁手握数据库的“生杀大权”?

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

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

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

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

长期稳定更新的攒劲资源: >>>点此立即查看<<<

具体可以这么操作:

立即学习“PHP免费学习笔记(深入)”;

  • 在phpMyAdmin中,进入 mysql 库,打开 user 表,切换到“搜索”页签。将关键权限字段如 Super_privGrant_privReload_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的“用户账户”页面确实方便,它会把权限分门别类地展示出来。但问题恰恰出在这里:像 SHUTDOWNPROCESS 这类全局权限,在图形界面里经常被折叠,或者归类得模糊不清,甚至干脆不显示。相比之下,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.dbmysql.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的图形界面里最不起眼,却恰恰是安全审计中最容易被遗漏的盲点。

侠游戏发布此文仅为了传递信息,不代表侠游戏网站认同其观点或证实其描述

热游推荐

更多
湘ICP备14008430号-1 湘公网安备 43070302000280号
All Rights Reserved
本站为非盈利网站,不接受任何广告。本站所有软件,都由网友
上传,如有侵犯你的版权,请发邮件给xiayx666@163.com
抵制不良色情、反动、暴力游戏。注意自我保护,谨防受骗上当。
适度游戏益脑,沉迷游戏伤身。合理安排时间,享受健康生活。