文章总结： 本文分析了phpMyFAQ2.9.8版本的CVE-2017-15734CSRF漏洞。该漏洞源于后台清除访问记录时未校验Token，诱导已登录管理员访问特定链接即可篡改数据。虽无法直接获取权限，但影响统计完整性。建议升级官方版本，并对后台敏感操作增加Token校验及避免使用GET请求改变状态。 综合评分： 83 文章分类： 漏洞分析,WEB安全,漏洞POC,安全开发

phpMyFAQ 2.9.8 被曝 CSRF 漏洞：一次“老问题”的典型复现

云梦DC

云梦安全

2025年12月29日 08:51 河南

CVE-2017-15734 / EDB-ID: 52459

有些漏洞并不“高级”，但却极其真实。 phpMyFAQ 2.9.8 中的这个 CSRF 漏洞，就是一个典型例子。

#

一、漏洞背景：phpMyFAQ 是什么？

phpMyFAQ 是一款基于 PHP 的开源 FAQ 管理系统， 常被用于：

• 企业知识库
• 内部文档系统
• 客服问答平台

由于其部署简单、后台功能集中，在不少内网和老系统中仍然可见。

二、漏洞概述：CSRF（跨站请求伪造）

本次漏洞编号为：

• CVE-2017-15734
• EDB-ID: 52459
• 影响版本：phpMyFAQ 2.9.8

漏洞类型： 👉 Cross-Site Request Forgery（CSRF）

简单来说就是一句话：

后台存在敏感操作，但没有做 CSRF Token 校验。

三、漏洞成因分析（技术视角）

🔍 问题出在哪里？

漏洞点位于后台统计模块：

phpmyfaq/admin/stat.main.php

通过后台入口文件：

phpmyfaq/admin/index.php

使用 action 参数进行功能分发。

⚠️ 问题核心

在以下操作中：

action=clear-visits

系统 没有校验 CSRF Token，仅依赖用户登录状态。

执行逻辑简化如下：

admin/index.php   └── 根据 action 参数        └── 加载 stat.main.php              └── 执行 clear-visits 操作

👉 只要用户已登录后台，请求就会被执行

四、漏洞利用条件（很重要）

这并不是“未授权访问”漏洞，它需要满足：

✅ 管理员已登录后台 ✅ 管理员具备清除访问记录的权限 ❌ 不需要再次确认 ❌ 不需要 CSRF Token

这正是 CSRF 的典型利用场景。

五、漏洞复现（PoC 说明）

目标请求

GET /admin/index.php?action=clear-visits

当管理员登录状态下访问该链接时：

• 访问统计数据会被直接清空
• 无任何提示或二次确认

演示 PoC（示意）

📌 场景说明：

• 管理员登录 phpMyFAQ 后台
• 在另一标签页 / 邮件 / 内嵌页面中加载该 HTML
• 请求会自动发出，操作立即生效

六、漏洞影响评估

虽然该漏洞不能直接获取数据或执行代码， 但仍然具有现实风险：

• ✅ 后台敏感操作可被“静默触发”
• ✅ 可破坏统计数据完整性
• ✅ 可作为社工攻击的一环
• ❌ 不涉及权限提升
• ❌ 不涉及数据泄露

📌 典型的“低危但真实”漏洞

七、为什么这种漏洞仍然值得关注？

原因只有一个：

它反映的是开发安全意识问题，而不是技术难度问题。

CSRF 防护并不复杂：

• Token
• SameSite Cookie
• Referer / Origin 校验

但在老系统或早期版本中，经常被忽略。

八、官方修复建议

如果你仍在使用 phpMyFAQ：

• 🔼 升级到官方已修复版本
• 🔐 后台所有敏感操作统一加入 CSRF 校验
• 🚫 避免使用 GET 执行状态改变操作

九、写在最后

这个漏洞并不“炫技”， 但它非常适合作为：

• 安全培训案例
• 老系统安全排查清单
• CSRF 风险讲解示例

真正的安全问题，往往不是“能不能打”， 而是“有没有想过防”。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：云梦安全 云梦DC《phpMyFAQ 2.9.8 被曝 CSRF 漏洞：一次“老问题”的典型复现》