MySQL权限提升主因是默认账户弱密码、SUPER/FILE权限滥用、危险功能未禁用及网络暴露；需删除匿名用户、禁远程root、启密码验证、限制监听地址、关闭local_infile等。
MySQL 默认账户和弱密码是权限提升的主入口
攻击者常从 root@localhost 或空密码、root 无主机限制的账户入手，一旦连上就能执行 GRANT、写入 mysql.user 表或利用 UDF 提权。生产环境绝不能保留默认配置。
- 删除匿名用户：
DROP USER ''@'localhost'; - 禁用远程 root 登录：
DELETE FROM mysql.user WHERE User='root' AND Host!='localhost';（之后必须FLUSH PRIVILEGES;） - 强制所有账户设强密码：用
VALIDATE_PASSWORD插件（5.7+），启用后SET GLOBAL validate_password.policy = STRONG; - 避免在命令行中明文传参密码，改用
mysql --defaults-file或mysql_config_editor存储凭据
慎用 SUPER 权限和 FILE 权限
SUPER 允许绕过大多数限制（如修改全局变量、杀其他会话），FILE 可读写服务器文件系统——这两个权限组合极易导致 RCE（如通过 SELECT ... INTO OUTFILE 写 Webshell）。
- 普通应用账号只授予最小必要权限，例如仅
SELECT, INSERT, UPDATE在指定库表上 - 禁止给应用账号授予
FILE；如需导入导出，改用LOAD DATA LOCAL INFILE（客户端侧读取，服务端不接触文件路径）并确保客户端已启用local_infile=OFF（服务端默认关闭） -
SUPER仅保留在 DBA 管理账号中，且该账号应通过跳板机 + SSH 隧道访问，不暴露在业务网络
禁用危险功能与插件可大幅缩小攻击面
MySQL 本身提供不少便利功能，但对安全敏感场景就是隐患源头。
- 关闭
local_infile：启动时加--local-infile=0，或运行时设SET GLOBAL local_infile = OFF;（需有SUPER） - 卸载非必要插件：
UNINSTALL PLUGIN daemon_example;、UNINSTALL PLUGIN rpl_semi_sync_master;（除非真用半同步复制） - 禁用符号链接支持：
skip-symbolic-links（防止通过CREATE TABLE ... DATA DIRECTORY跳出 datadir） - 不要启用
query_cache_type=1（旧版 MySQL 中存在绕过权限检查的缓存污染漏洞，8.0 已移除）
连接层和网络层必须做隔离
MySQL 自身权限模型再严，也挡不住未授权连接。很多“提权”实际是未鉴权直接连上导致的。
- 绑定监听地址：配置
bind-address = 127.0.0.1（仅本地）或具体内网 IP，严禁0.0.0.0或注释掉该行 - 使用防火墙限制源 IP：
iptables -A INPUT -p tcp --dport 3306 -s 192.168.10.0/24 -j ACCEPT，其余全拒 - 应用连接串中避免硬编码账号密码，改用 Vault 或 K8s Secret 注入，并定期轮换凭证
- 启用 TLS（
require_secure_transport=ON），否则所有流量（含密码）明文传输，中间人可直接截获并重放登录
MySQL 权限提升不是单点问题，而是账户策略、功能开关、网络边界、运行时配置四层叠加失效的结果。最容易被忽略的是：开发测试环境照搬生产权限模板，却长期开着 skip-grant-tables 或 local_infile；还有 DBA 习惯用 root 连接所有实例，一次疏忽就可能让整个集群裸奔。
