如何在phpMyAdmin中禁用特定服务器的导出功能以保安全？-phpMyAdmin-PHP中文网

必须通过mysql权限回收（revoke file）+ config.inc.php中针对$cfg['servers'][$i]的独立php拦截（die('export disabled for this server')）实现单服务器导出禁用，而非修改全局$cfg['export']。

只禁用某个服务器的导出，不能动全局 `$cfg['export']`

phpmyadmin 的 $cfg['export'] 是全局配置，设为 false 会干掉所有服务器的导出入口，不满足“特定服务器”需求。真要按服务器粒度控制，得靠 mysql 权限 + phpmyadmin 配置组合实现。

核心思路：让该服务器连接所用的数据库账号，根本没能力执行导出依赖的操作。

确保该账号没有 FILE 权限：REVOKE FILE ON *.* FROM 'user'@'host'; —— 没这个权限，SELECT ... INTO OUTFILE 和服务端导出直接失败
在 config.inc.php 中，对该服务器单独关闭导出相关功能项：
```
$cfg['Servers'][$i]['AllowRoot'] = false;
$cfg['Servers'][$i]['DisableIS'] = true;
$cfg['Servers'][$i]['hide_db'] = '^(information_schema|mysql|sys)$';
```
这些虽不直接关导出按钮，但能大幅压缩攻击面，让普通用户连元数据都看不到，自然难构造有效导出请求
不要给该服务器配 $cfg['Servers'][$i]['SaveDir'] 或 $cfg['Servers'][$i]['UploadDir'] —— 空字符串或未定义，可禁用“导出到服务器”和“从服务器导入”两个高危通道

`export.php` 仍能被访问？得在 PHP 层做路由拦截

即使按钮消失、权限收紧，已登录用户仍可能手动 POST 到 export.php 或 sql.php，带上 export_type=sql 参数绕过前端限制。这不是界面问题，是后端逻辑漏洞。

必须在 config.inc.php 末尾（?> 前）加运行时拦截：

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

if (basename($_SERVER['SCRIPT_NAME']) === 'export.php' && isset($_POST['what'])) {
    die('Export disabled for this server');
}
if (basename($_SERVER['SCRIPT_NAME']) === 'sql.php' && !empty($_POST['export_type'])) {
    die('Export disabled for this server');
}

这两段代码只生效于当前配置块作用域内的服务器（即 $i 对应的那个），不影响其他服务器
注意判断条件要严格：isset($_POST['what']) 比 !empty($_POST) 更精准，避免误杀正常 SQL 执行
别用 header('Location: ...') 跳转——容易被绕过；die() 是最直接的中断方式

为什么不能删 `export.php` 或改源码？

有人试过直接删 export.php 或注释掉 tbl_export.php 里的逻辑，结果发现：升级后文件被覆盖，或者新版本用新路径绕过，甚至报错后反而暴露更多调试信息。

phpMyAdmin 升级会完全替换 export.php 等核心文件，手工修改不可持续
某些版本导出逻辑已拆进 libraries/classes/Export/ 下多个类中，硬改源码极易出错且无意义
Web 服务器层（如 Nginx）用 location ~ /export\.php$ { return 403; } 看似简单，但会拦住所有用户（包括管理员），无法做到“仅限某服务器”

最后检查点：导出按钮没了 ≠ 导出能力消失

禁用效果是否真正落地，不能只看界面。务必验证三件事：

用该服务器账号登录后，点击任意表的「导出」，是否跳转 404 或显示 Export disabled for this server
手动构造 POST 请求：curl -X POST http://pma.example.com/export.php --data "what=table&export_type=sql"，确认返回明确拒绝信息，而非空白页或错误堆栈
检查 MySQL 日志，确认没有 INTO OUTFILE 或 SELECT ... INTO DUMPFILE 类语句被执行成功

最容易被忽略的是：你禁了导出，但忘了撤掉 FILE 权限。只要权限还在，攻击者换条路（比如通过 SQL 标签页直接执行）就能写文件。权限回收和配置拦截，缺一不可。