撤掉MySQL用户FILE权限是核心防线，需执行REVOKE FILE ON . FROM 'user'@'host';并FLUSH PRIVILEGES；同时清空phpMyAdmin的UploadDir/SaveDir、禁用sql/php导出格式、使用低权限账号登录。
撤掉 MySQL 用户的 FILE 权限是核心防线
phpMyAdmin 本身没有「禁用导入」开关，但所有通过 LOAD DATA INFILE、SELECT INTO OUTFILE 或后台解析 .sql 文件触发的文件读写行为，最终都依赖 MySQL 的 FILE 权限。只要这个权限还在，攻击者或误操作用户就可能绕过前端限制执行危险操作。
必须执行以下命令（以管理员身份登录 MySQL）：
-
REVOKE FILE ON *.* FROM 'username'@'host';—— 注意是ON *.*，因为FILE是全局权限，不能指定数据库 -
FLUSH PRIVILEGES;—— 确保立即生效，尤其在直接改表后 - 若用户属于角色（MySQL 8.0+），还需检查并从角色中同步撤回
FILE
验证方式：用该用户登录后执行 SELECT 1 INTO OUTFILE '/tmp/test.txt';，应返回 ERROR 1045 (28000): Access denied，而非路径相关错误。
清空 $cfg['UploadDir'] 和 $cfg['SaveDir'] 阻断上传路径
即使用户有权限，没地方存文件也执行不了。在 phpMyAdmin 的 config.inc.php 中，把这两个配置设为空字符串：
立即学习“PHP免费学习笔记（深入）”；
-
$cfg['UploadDir'] = '';—— 导入页仍显示文件选择框，但上传会报Cannot upload file -
$cfg['SaveDir'] = '';—— 禁止保存导出结果，也防止恶意用户把导出内容存到 Web 可访问路径
别设成 'upload' 或相对路径——这反而制造了可写目录，一旦配合其他漏洞（如文件包含），风险更大。空值才是明确拒绝。
禁用高危导出格式，减少脚本复用机会
导出功能本身不危险，但导出为 sql 或 php 格式，等于帮攻击者打包好可直接执行的脚本。非 DBA 账号应限制导出选项：
-
$cfg['Export']['format'] = ['csv', 'json'];—— 只保留结构简单、无执行能力的格式 - 移除
'sql'后，用户无法一键导出带CREATE/INSERT的完整脚本，降低被用于横向迁移的风险 - 注意：此配置不影响已有 SQL 文件上传，它只控制「导出」下拉菜单里的选项
如果你的业务确实需要 sql 导出，至少确保对应账号没有 FILE 权限，否则导出的文件可能被重定向写入任意路径。
低权限账号登录才是最实际的隔离手段
很多团队花时间隐藏按钮、删 import.php、甚至改 Apache 配置屏蔽路径，但只要用户已登录且拥有数据库上下文，就能在 sql.php 页面粘贴 500 行建表语句——这本质上仍是「执行外部脚本」。
真正有效的做法是让非 DBA 用户根本看不到导入入口：
- 创建专用账号，仅授予目标数据库的
SELECT、INSERT、UPDATE，**不勾选任何全局权限**（尤其是SUPER、FILE、PROCESS） - 确保该账号连
SHOW DATABASES都被拒绝——这样用户登录后直接进不了「导入」页面的数据库选择上下文 - 避免使用
'%'作为 host；对内网管理账号，限定为'192.168.1.%'或具体 IP
最容易被忽略的是：secure_file_priv 设置为空或 NULL 并不能替代权限回收。它只是让 LOAD DATA 报错更早，但只要 FILE 权限还在，攻击者仍可能利用其他向量（如 UDF、日志写入）达成类似效果。防线重心永远在权限最小化，不在配置项堆砌。
