记录第一次尝试 CMS 漏洞挖掘

枫桥2026/6/6大约 11 分钟

记录第一次尝试 CMS 漏洞挖掘

这篇文章整理的是我第一次比较完整地尝试 CMS 漏洞挖掘的过程。目标是本地搭建的 xxCMS v1.6 靶场，范围只限自己的测试环境。原始记录更像一份漏洞报告，这里把它改成一次复盘：先讲我是怎么找入口的，再按前台、后台和文件暴露三个方向整理漏洞，最后写一下这次真正学到的东西。

测试环境

测试目标：

http://localhost/xxcms/

基础环境：

Apache/2.4.23 (Win32)
PHP/5.2.17
MySQL 5.5.53
xxCMS v1.6
字符集：gb2312 / gbk

漏洞一览

这次一共整理出下面这些问题。它们不是彼此孤立的点，组合起来可以形成一条从信息搜集、前台注入、后台进入到文件操作和数据泄露的链路。

模块	问题	影响
安装模块	安装目录未锁定	可能被重新安装或覆盖配置
前台注册	用户名校验宽字节 SQL 注入	可判断注入成立，进一步影响用户校验逻辑
前台注册	验证码复用	可批量注册测试账号
新闻发布	文章概要存储型 XSS	首页访问时触发脚本
前台登录	缺少爆破限制	可对弱口令进行在线爆破
前台登录	万能密码与盲注	可绕过登录或枚举数据库
支付流程	文件包含 / 路径控制	可影响页面加载路径
后台登录	万能密码与时间盲注	可验证后台登录 SQL 注入
模板管理	任意文件写入	后台权限下可写出文件
数据库管理	路径穿越任意文件删除	后台权限下可删除目录外文件
用户管理	后台任意重置前台用户密码	可接管指定前台账号
备份目录	备份文件名可猜测且可直接下载	数据库备份泄露

信息搜集

第一步还是找入口。目录扫描、robots.txt 和手工访问结合起来，比只跑一个扫描器有效很多。

python dirsearch.py -u http://localhost/xxcms/ -e*

确认到的高价值路径：

/admin/                       后台入口
/install/                     安装向导残留
/data/                        数据与备份目录
/templates/                   模板目录
/include/fckeditor/           富文本编辑器组件
/user.php                     前台登录、注册、支付和个人中心入口
/comment.php                  评论入口
/api/                         API 相关入口

组件识别方面，能确认目标是 xxCMS v1.6，并且还带着老版本 FCKeditor 的文件管理相关接口。

http://127.0.0.1/xxcms/include/fckeditor/editor/filemanager/connectors/test.html

前台和后台的功能面也比较清晰：前台有注册、登录、新闻发布、支付模块；后台有登录、模板管理和数据库管理。

前台漏洞

安装模块未锁定

访问 /install/ 后发现安装流程仍然可访问，没有看到明显的安装锁定文件或完成后的禁止访问逻辑。这类问题在真实环境里很危险，因为攻击者可能尝试重新安装、覆盖配置或借安装步骤读取环境信息。

修复思路很直接：安装完成后删除安装目录，或生成安装锁文件，并在入口处强制检测。

注册页用户名校验宽字节注入

注册页会先判断用户名是否可用。正常输入一个不存在的用户名时，页面提示可以注册。

随后把用户名改成宽字节注入 payload：

%df%27%20or%201=1%23

页面从“可以注册”变成“该用户名已存在”，说明用户名校验位置可以被注入条件影响。

这个点的关键不是 payload 本身，而是环境字符集：目标使用 gb2312 / gbk，如果代码只做了简单转义，就可能被宽字节绕过。修复时不能继续靠手写过滤，应该统一编码处理，并改用参数化查询。

验证码复用导致批量注册

在 Burp 历史记录里对比多次注册请求时发现，不同用户注册时可以使用同一个 PHPSESSID 和同一个验证码完成提交。

验证码应该是一次性校验值，成功使用后需要立即失效。否则它只能证明“曾经输入对过”，不能证明“这一次请求的人真的刚刚完成验证”。

文章概要存储型 XSS

使用注册账号登录后，在新闻发布页面测试文章概要字段。payload 只用于本地验证，不做外带。

<script>document.body.setAttribute("data-xss","nnn")</script>

回到首页后，脚本被浏览器执行，说明文章概要字段存在存储型 XSS。

这个问题的修复点在输出侧：写入数据库前可以做基础校验，但真正决定 XSS 是否触发的是展示时有没有按 HTML 上下文做编码。

前台登录缺少爆破限制

用前台注册账号 wobuzai 做登录爆破测试，可以看到登录接口没有明显的失败次数限制、延迟、验证码升级或账号锁定机制。

爆破成功后可以正常进入账号。

这类问题本身未必是高危漏洞，但它会放大弱口令、默认口令和信息泄露带来的风险。

前台登录万能密码与盲注

前台登录处继续测试宽字节注入，可以构造万能密码式 payload：

1%df%27%29%20OR%201=1%23

随后把登录请求保存成 sqlmap request 文件，对用户名参数进行盲注验证：

python sqlmap.py -r "D:\Users\Administrator\Desktop\.txt" --batch

确认注入后，继续获取当前库名：

python sqlmap.py -r "D:\Users\Administrator\Desktop\.txt" --batch --current-db

再枚举表：

python sqlmap.py -r "D:\Users\Administrator\Desktop\.txt" --batch -D root --tables

最后尝试导出后台管理员表：

python sqlmap.py -r "D:\Users\Administrator\Desktop\.txt" --batch -D root -T bbs_admin --dump

这里同时暴露出一个环境问题：数据库账号密码是 root/root。在本地靶场里很常见，但在真实环境里会进一步扩大损害。

支付流程文件包含

在 user.php?act=buy 相关流程中，支付页面路径可以被影响。把支付路径改成目录穿越形式后，页面返回到网站首页，说明加载路径存在可控空间。

http://localhost/xxcms/user.php?act=buy

这类问题的修复重点是白名单：支付方式不应该直接映射到用户可控路径，而应该映射到固定枚举值。

后台漏洞

后台登录万能密码

后台入口位于：

http://localhost/xxcms/admin/login.php?act=login

尝试宽字节万能密码 payload：

%df%27)%20or%201=1%23

后台登录和前台登录一样，根因仍然是 SQL 拼接与字符集处理问题。

后台登录时间盲注

继续在后台登录请求里把 admin_pwd 参数改成时间盲注 payload：

%df%27)%20or%20if(1=1,sleep(20),0)%23

响应时间显著变长，说明后台登录处也存在可被利用的注入点。

模板管理任意文件写入

进入后台后，模板管理功能存在 act=do_edit 写模板逻辑。如果 tpl_name 可以指向模板目录外，就会变成任意文件写入。

访问写入位置后，可以看到文件成功落地。

修复思路是对路径做规范化后再校验根目录，不能只靠字符串里有没有 ../。同时模板管理应限制可编辑文件后缀和目录。

数据库管理路径穿越任意文件删除

后台数据库管理功能可以删除备份文件。测试时先在 data/upload/ 下放一个 poc.php，再通过数据库管理删除逻辑进行路径穿越。

随后访问原文件路径，发现文件已经被删除。

http://localhost/xxcms/data/upload/poc.php

删除类功能比读取类功能更需要谨慎：一旦路径可控，影响可能直接变成破坏性操作。

后台任意重置前台用户密码

在后台用户管理界面修改用户密码时，流程没有额外校验原密码或二次确认。拿到后台权限后，可以直接重置指定前台用户密码。

前台使用新密码 Reset123! 可以登录。

严格来说，这是后台权限内的高危功能滥用点。更合理的设计是记录审计日志、要求二次确认，并避免在普通管理权限下直接改写敏感账号凭据。

备份文件泄露

后台数据库备份文件使用日期形式命名，例如 20241108.sql。这种命名规则很容易被猜测。

退出登录后，直接访问备份路径仍然可以下载：

http://192.168.137.110/xxcms/data/backup/20241108.sql

备份目录应该放在 Web 根目录外。如果必须放在站点目录内，也至少要配置 Web Server 拒绝直接访问。

利用链复盘

这次比较完整的一条链路可以这样理解：

通过目录扫描和组件识别发现 /install/、/admin/、/data/backup/ 和 FCKeditor 接口。
从前台注册和登录入口确认宽字节 SQL 注入。
通过登录盲注进一步确认数据库结构和后台账号信息。
进入后台后，模板管理可以写文件，数据库管理可以删除文件。
备份目录又提供了独立的数据泄露面，即使不登录也能直接下载备份。

这里最重要的感受是：单点漏洞当然重要，但真正影响系统安全的，是这些点能不能相互接起来。信息泄露会帮助注入，注入会帮助进入后台，后台功能缺陷又会放大成文件级操作。

修复建议

按优先级整理一下：

删除或锁定 /install/，安装完成后禁止再次访问。
所有 SQL 查询改为参数化查询，不再手写拼接和转义。
统一字符集，避免 GBK 宽字节绕过。
验证码使用后立即失效，并绑定具体业务动作。
登录接口增加失败次数限制、延迟、验证码升级和日志告警。
新闻概要等富文本或半富文本字段输出时按上下文编码。
文件包含、模板编辑、备份删除等路径参数改为白名单映射。
备份文件移出 Web 根目录，并禁止目录遍历和直接下载。
后台敏感操作增加二次确认和审计日志。
删除默认弱口令，数据库账号按最小权限配置。

写在最后

这是第一次把 CMS 漏洞挖掘从“我好像找到了几个洞”整理成“入口、证据、影响、修复、链路”的完整记录。过程里踩了很多细节：字符集、验证码状态、后台权限边界、文件路径规范化、备份目录访问控制。以后继续做类似目标时，我会先把资产面列出来，再围绕“输入点、鉴权点、文件点、备份点”四类位置做最小验证。

这篇就当作博客的第一篇文章。不是最成熟的一篇，但它确实是我第一次把一次漏洞挖掘认真收束成文。