phpMyAdmin如何修复文件包含漏洞

验证phpMyAdmin是否受CVE-2014-8959或CVE-2018-12613影响，需先查版本号，再分别用PoC测试GIS路径和target参数绕过，升级后必须清理旧libraries/gis/目录并更新core.php中checkPageValidity()函数，同时配置Web服务器层拦截规则。

如何验证当前 phpMyAdmin 是否受 CVE-2014-8959 或 CVE-2018-12613 影响

先确认版本和漏洞面，比盲目打补丁更关键。受影响版本不是“所有旧版”，而是有明确范围的：

1. grep -r "$this->PMA_VERSION" /path/to/phpmyadmin/ | head -n 1 查版本号
2. CVE-2014-8959：影响 4.0.x（4.0.10.13 前）、4.1.x（4.1.14.7 前）、4.2.x（4.2.12 前）
3. CVE-2018-12613：影响 4.8.0–4.8.1，核心在 index.php 的 target 参数双重解码绕过

别只看主版本号——有些定制包改了 PMA_VERSION 却没修代码。真实风险得靠 PoC 验证：

1. 访问 /libraries/gis/pma_gis_factory.php?gis_type=../../../../etc/passwd%00，返回文件内容即中招
2. 访问 index.php?target=db_sql.php%253f/../../../../etc/passwd（%253f 是 ? 的双重编码），能读取即未修复 CVE-2018-12613

升级后必须清理旧 GIS 目录，否则补丁无效

很多团队升级完以为万事大吉，结果漏洞仍在。根本原因是：CVE-2014-8959 的载体是 libraries/gis/ 下的硬编码逻辑，新版虽重写了 pma_gis_factory.php，但若旧目录残留，请求仍可能命中老文件。

1. 必须手动删除整个 libraries/gis/ 目录，再从新包完整复制过去
2. 检查是否还存在废弃入口 gis_data_editor.php，它在 4.3+ 已移除，若残留需一并删掉
3. 新版路由应为 ?route=/gis，旧路径如 gis_data_editor.php 必须返回 404

不清理旧目录 = 补丁打在空气上。Apache/Nginx 层拦截 gis_type=.*.. 只是临时缓解，不能替代这一步。

修复 index.php 中 target 参数绕过的三处关键修改

CVE-2018-12613 的根源不在过滤弱，而在校验逻辑被二次 urldecode() 破坏。最新 4.9.0+ 的修复不是加正则，而是重构校验流：

1. 删掉 index.php 第 465 行左右的 urldecode($page) —— 它出现在 checkPageValidity() 的第二次校验分支里，纯属冗余且危险
2. 在 checkPageValidity() 函数开头加 $page = strtok($page, '?');，强制截断问号后全部内容，防 %253f 类绕过
3. 确认 $target_blacklist 至少包含 import.php、export.php，且白名单页面（如 db_sql.php）必须严格全匹配，不允许带任何查询参数

只改 index.php 不够——core.php 中的 checkPageValidity() 必须同步更新，否则攻击者可从其他调用路径绕过。

Web 服务器层必须封堵典型 payload，不能只依赖 PHP 层

PHP 层修复可能被绕过（如三次编码 %25253f、双问号 %253f%253f），Nginx/Apache 规则提供兜底：

1. Nginx：if ($args ~* "target=.*%253f") { return 403; } 放在 phpMyAdmin 的 location 块内
2. Apache：RewriteCond %{QUERY_STRING} target=.*%253f [NC] + RewriteRule ^ - [F]
3. 关键路径屏蔽：location ^~ /var/lib/php/sessions/ { return 403; }，阻断 session 文件包含链

这些规则要配合 PHP 层修复一起生效。单独开任一层，都可能被高阶 payload 绕过。真正难搞的是登录态下 SQL 插入 PHP 代码再包含 session 的链式利用，必须用真实 payload 复测。