Joomla注册绕过与提权：CVE-2016-8869/8870拆解及加固排查

Joomla 未授权创建特权用户这个问题，到今天还有人在翻旧账。CVE-2016-8869 和 CVE-2016-8870 这两个编号经常成对出现，很多刚接触内容管理系统安全审计的朋友会把它们当成同一个洞的两个变种，其实两者的触发点和绕过逻辑并不一样，只是组合起来能把危害放大到极致——注册开关关掉的站点，照样能凭空冒出一个超级管理员。我这次把这两个编号拆开重讲一遍，不是抄公告，而是从框架的表单模型、用户对象绑定、控制器判断这三个层面，把“为什么这段代码会被绕过”讲清楚，顺带把实验复现、日志侧证据、补丁对照、上线后的加固和排查清单都摆出来。适合三类人看：做 CMS 二开和运维的同学、刚开始接触漏洞分析的入门者、以及手里还挂着一批老站需要做资产梳理的人。哪怕你只懂 PHP 语法，跟着思路走也能看明白这条链路是怎么断的。

1. 漏洞背景与影响范围盘点

1.1 两个编号到底是不是同一个洞

先把最容易混淆的地方说清楚。CVE-2016-8869 的核心问题是用户注册流程对用户组参数处理不当，攻击者可以在注册提交的数据里夹带用户组信息，让新建账号直接落进高权限组；CVE-2016-8870 的核心问题是注册入口的开关判断不严，即使管理员在后台把“允许用户注册”关掉了，注册控制器依然能接受请求并完成建号。前者是“权限给错了”，后者是“门没锁”。

单看任何一个，危害都有限：8869 需要站点本身开放注册，8870 只能建出普通账号。两者串起来，就变成“门没锁 + 进去直接给你管理员钥匙”。这也是当年大批站点被批量挂马的根本原因——整个攻击过程不需要任何已有账号，不需要猜密码，也不需要后台路径。

理解这一点很重要，因为它决定了你的修复策略不能只做一个方向。只升到“关闭注册”是没用的，只改用户组默认值也堵不住绕过入口的问题。审计的时候看到 3.4.4 到 3.6.3 这个区间，两个编号必须一起查。

1.2 影响版本的精确边界与真实攻击面

版本边界要卡准，不然容易漏资产。CVE-2016-8869 影响 3.4.4 到 3.6.3；CVE-2016-8870 影响 3.6.3 及更早。两者共同覆盖的区间是 3.4.4 到 3.6.3，修复版本是 3.6.4。也就是说，判断一个站点是否中招，看它的版本号落在 3.4.4 至 3.6.3 之间就够了，不需要逐个组件比对。

真实攻击面比版本号看起来更大。很多站点的前台注册页被模板或第三方插件改造过，走了自定义的注册入口，但底层仍然调用同一套模型和用户对象。这类改造站点做版本排查时容易被忽略，因为它们的外观和默认站完全不同。还有一种情况是站点做了多语言、多站点共享用户表，主站升级了，子站还挂着旧代码，用户表却是同一张——这种环境下，修一个等于没修。

我在梳理资产时习惯用两条线交叉验证：一条是文件系统里的版本声明文件，另一条是数据库里用户表最近的注册记录。前者告诉你“应该是什么版本”，后者告诉你“实际跑的是什么行为”，两者对不上就说明有二次开发覆盖。

1.3 一个八年前的老洞，为什么现在还要看

有人会问，2016 年的洞，官方几个月就修了，还值得花时间？值得，原因有三个。

第一，存量。内容管理系统的升级惰性在所有技术栈里都算突出的，模板、插件、二次开发的耦合让升级成本极高，一批站点常年停在某个能跑就行的版本上。第二，内网资产。外网暴露的站点多少有人盯，内网里跑着的老系统往往没人管，而这类系统的账号体系经常和内部其他系统打通，一个超级管理员账号的价值远超一台普通主机。第三，分析方法。这个漏洞的成因非常典型——表单字段白名单、模型层数据校验、控制器状态判断三处职责边界模糊，导致每一层都以为别人会拦。这个模式在后来的无数 Web 框架漏洞里反复出现，把这套链路吃透，比记住一百个 CVE 编号有用。

提示：本文所有复现描述均针对自建实验环境，用于理解原理和验证修复效果。任何对非授权系统的测试都不在讨论范围内。

2. 漏洞根因拆解：请求到落库的完整链路

2.1 先搞懂框架的四层结构

不理解结构，看代码只会眼花。这套内容管理系统的用户注册流程分四层，职责大致如下。

控制器层负责接请求、验令牌、取参、调用模型、决定跳转。模型层负责加载表单定义、校验数据、调用用户对象保存。表单层由一份 XML 定义文件描述，规定哪些字段存在、各自用什么过滤规则。用户对象层负责把数据绑到对象属性上，最终写用户表和用户组映射表。

问题就出在这四层的衔接缝隙里。控制器从请求里取数据时用的是原始数组，表单层负责按 XML 白名单过滤，模型层负责再做一次校验，用户对象层负责绑定。听起来层层设防，实际每一层都假设“上一层已经处理过了”。表单 XML 里如果声明了某个字段，它就会顺利通过过滤；过滤后的数据进了模型，模型不去判断这个字段该不该由用户提交；用户对象层看到数组里带用户组，就老老实实照着绑。

这个结构本身没问题，问题在于表单 XML 的字段定义被当成了安全边界。字段定义本来是给渲染用的，它描述的是“页面上要显示什么”，而不是“哪些字段允许用户提交”。把渲染定义当白名单用，等于让前端展示逻辑承担后端安全职责，出事只是时间问题。

2.2 注册表单里那个不该能提交的字段

关键字段是用户组。注册页面上，某些配置下会显示用户组选择项（通常是只读或默认选中），对应的 XML 定义里就存在这个字段名。表单过滤按 XML 遍历字段，字段在定义里，它的值就会被保留并进入后续流程。

// 表单过滤的简化逻辑，仅示意字段白名单的工作方式 foreach ($form->getFieldset($group) as $field) { $name = $field->getAttribute('name'); $filter = $field->getAttribute('filter') ?: 'cmd'; if (isset($data[$name])) { $result[$name] = $this->filterField($data[$name], $filter); } }

上面这段是简化示意。它的含义是：过滤结果只覆盖 XML 里声明过的字段，声明了就保留，没声明就丢弃。所以“能不能提交用户组”完全取决于 XML 里有没有这一项，而开发者当时的意图只是“让页面能显示”，并没有意识到这一项同时也意味着“允许提交”。

用户组参数是一个数组结构，元素是组 ID 的整数值。默认安装下，组 ID 与角色的对应关系是固定的：1 是公开，2 是注册用户，3 是作者，4 是编辑，5 是发布者，6 是管理员，7 是后台管理员，8 是超级管理员。这些 ID 在安装时会写入用户组表，二次开发或插件可能改变它们，所以审计时不能死记数字，必须查表确认。

2.3 为什么“关闭注册”这道闸门没顶住

这是 8870 的核心。后台有一个开关控制前台是否允许自助注册。看代码会发现，这个开关的判断放在表单加载环节：开关关闭时，模型返回表单失败，控制器拿到失败结果后理论上应该中止流程并提示错误。

问题在于控制器拿到失败结果后的处理分支不够彻底。不同小版本的写法略有差异，有的版本在拿到失败后仍然继续往下走，有的版本把错误提示和流程中止分开了——提示归提示，流程归流程。结果就是：前台页面不再显示注册表单了，但注册任务的入口地址依然接受请求，请求进来后建号逻辑照常执行。

用一个类比说明。这相当于商场把“入口处的登记台”撤了，但工作人员只负责检查登记台在不在，不检查人是从哪进来的。门没了，通道还在。

这里还有个常被忽略的点：CSRF 令牌。注册请求需要携带令牌，看起来像一道防护，但注册页面对外公开，令牌就藏在页面源码的隐藏字段里，取一次拿来用就行。所以令牌在这里只能防跨站伪造，防不住直接构造请求。很多人在审计时看到令牌就放过，这是误判。

2.4 用户对象层的“宽容”埋了最后一颗雷

数据走到用户对象层，就到了落库前最后一关。这一层的绑定方法接受一个关联数组，逐项赋值给对象属性。对用户组的处理逻辑大致是：如果数组里带了用户组并且是数组结构，就清空原有组，逐个追加，数字直接转整型写入，非数字则尝试按用户解析。

// 绑定用户组的简化逻辑示意 if (isset($data['groups']) && is_array($data['groups'])) { $this->groups = []; foreach ($data['groups'] as $group) { if (is_numeric($group)) { $this->groups[] = (int) $group; } } }

这段逻辑本身没有错，它承担的是“数据已经可信”的前提。它的宽容是为了支持后台管理员手工调整用户组，但同一个方法被前台注册流程共用，前提就不成立了。保存阶段再把组 ID 写入用户与用户组的映射表，一个超级管理员账号就诞生了。

这一层的教训最值得记：同一个数据模型被不同信任级别的入口共用时，必须在模型内部做权限边界判断，而不是依赖调用方自觉。修的时候在模型里强制覆盖用户组，就是把这个边界收回到模型自身。

2.5 一条完整的因果链

把上面四点串起来：控制器取了原始请求数据并且在中止分支上不彻底，表单 XML 意外地把用户组列入了可提交字段，模型层没有对用户组做来源判断，用户对象层照着数据绑定并落库。四层里任意一层做了正确的边界判断，这个洞都不成立；四层全都指望别人，洞就成立了。

这也解释了为什么修复补丁要动三个地方而不是一个：加控制器判断、模型强制覆盖、表单字段剔除。三处同时改，才算把职责边界重新划清。

3. 实验环境搭建与验证思路

3.1 环境准备与版本选择

实验环境建议用虚拟机或容器，隔离网络，只在内部访问。版本上选 3.6.3 作为“有问题”的样本，选 3.6.4 作为“已修复”的对照样本。两个版本跑在同一台宿主机上的不同端口或不同容器里，便于对比行为差异。数据库用同一套初始化脚本，保证组 ID 一致，避免因为安装差异导致结论对不上。

安装时留意两个配置项：一是安装过程中的示例数据选项，装不装会影响用户组表的初始内容；二是安装完成后到后台把站点注册开关改成关闭，这是复现 8870 的必要条件。很多人复现失败就是因为默认开着注册，攻击路径走的是 8869 而不是组合路径，结论自然对不上。

装完先做一次基线记录：把用户表、用户组表、用户组映射表各导一份快照，记下当前的用户数和最大用户 ID。后面所有验证都基于这份快照做 diff，一眼就能看出新增了什么。

# 导出基线快照，表前缀按实际安装填写 mysqldump -u dbuser -p dbname prefix_users > users_baseline.sql mysqldump -u dbuser -p dbname prefix_usergroups > groups_baseline.sql mysqldump -u dbuser -p dbname prefix_user_usergroup_map > map_baseline.sql

3.2 先查表，把组 ID 摸清楚

不要凭记忆用 ID，一定要查。安装来源不同、插件不同，组 ID 可能完全不一样。查完把结果记下来，后面读日志和读数据库都要用。

-- 查看用户组与父级关系，确认哪个是高权限组 SELECT id, parent_id, title FROM prefix_usergroups ORDER BY id; -- 查看当前每个组里有几个用户，异常增长的就是可疑组 SELECT group_id, COUNT(*) AS cnt FROM prefix_user_usergroup_map GROUP BY group_id ORDER BY cnt DESC;

跑完第二条你会看到高权限组通常人很少，个位数。这个特征在事后排查里非常有用：一个正常运营的站点，超级管理员组的成员数长期稳定，一旦出现增长，就值得立刻回查注册时间。

3.3 请求结构的观察方法

理解请求结构不需要构造攻击脚本，把正常注册请求抓下来逐字段改就行。正常注册请求发往注册任务入口，携带一组表单字段：姓名、用户名、两遍密码、两遍邮箱，外加令牌和任务名。全部在请求体里以表单编码方式提交。

关键观察点是：请求体里多出一个用户组数组字段时，服务端会怎么处理。在 3.6.3 上，多出来的这个字段会被完整接受，账号建好后直接落在指定组；在 3.6.4 上，这个字段被忽略，账号落在后台配置的默认组里。这个对比实验能让你直观理解“字段白名单”和“字段剔除”的差别。

观察时建议同时开三个窗口：一个是响应结果，一个是数据库查询，一个是服务器访问日志。响应结果告诉你流程走没走通，数据库告诉你落库结果，日志告诉你请求长什么样。三者对齐，结论才扎实。

3.4 日志侧留下了什么痕迹

日志是事后排查的主战场。Web 访问日志里，这类请求的特征相当明显：请求方法为 POST，路径指向站点的入口文件，查询串里带组件名和注册任务名，请求体里出现用户组相关的字段名。字段名里的方括号是关键特征，正常的注册请求不会带这类结构。

还有一类痕迹在数据库侧。用户表里新增记录的注册时间会集中在某个时间段，激活状态字段往往是“无需激活”或“已激活”，邮箱域名常见一次性邮箱或明显编造的值。把这些记录和映射表关联起来，就能拉出完整的“谁在什么时候被塞进了哪个组”。

-- 拉出高权限组成员及其注册信息，用于人工核对 SELECT u.id, u.username, u.email, u.registerDate, m.group_id FROM prefix_users u JOIN prefix_user_usergroup_map m ON m.user_id = u.id WHERE m.group_id IN (7, 8) ORDER BY u.registerDate DESC;

上面这条语句里的 7 和 8 只是默认安装下的常见值，实际使用前必须换成你在 3.2 节查出来的真实 ID。

4. 修复方案与加固落地

4.1 官方补丁动了哪三个地方

补丁的思路就是把职责边界重新划清楚，三处改动互相配合。

第一处，注册控制器补上注册开关的判断，开关关闭时直接中止，不再往下走。这样“门没锁”的问题从入口处堵上。第二处，模型层在调用用户对象保存之前，强制把用户组覆盖为后台配置的默认新用户组，不管请求里带了什么，一律覆盖。第三处，表单定义里把用户组字段从可提交字段中剔除，让它只参与展示，不参与数据收集。

// 模型层强制覆盖用户组的思路示意，非官方原始代码 $params = JComponentHelper::getParams('com_users'); $defaultGroup = (int) $params->get('new_usertype', 2); $data['groups'] = [$defaultGroup];

三处改动里，模型层覆盖是最关键的一道。因为即使前两道被二次开发改坏了，模型层覆盖仍然能兜底。判断一个站点是否真的修好了，重点就看模型层有没有这行强制赋值——只升级文件不改二次开发代码的站点，经常在这一层被改回去。

4.2 不能立刻升级时的临时缓解

现实里很多站点短期内升不了级，模板和插件耦合太深，一动就白屏。这种情况下有几步可以做，按优先级排。

第一步，前台关闭注册，同时确认注册任务入口在关闭状态下确实返回错误页。这一步只解决 8870 的一半，因为有些版本关不掉，所以必须实测。

第二步，在反向代理或应用层加请求过滤，拦截注册任务请求中携带数组型用户组字段的提交。规则写法要注意，不要只匹配固定字段名，要匹配“注册任务 + 请求体含数组结构字段”的组合特征，避免误伤正常业务。

# 反向代理层的拦截思路示意，需按实际业务调整 if ($request_method = POST) { set $block_reg 0; if ($args ~* "option=com_users") { set $block_reg 1; } if ($request_body ~* "jform\[groups\]") { set $block_reg 1$block_reg; } if ($block_reg = 11) { return 403; } }

注意：上面这段只是思路示意。生产环境用条件判断容易踩坑，更稳的做法是交给应用层过滤器或专门的请求检测模块处理，并且先在预发环境验证误伤率。

第三步，收紧高权限组。把超级管理员组的成员数压到最少，后台开启双因素认证，管理员账号与前台账号体系在命名上做区分，便于人工识别异常账号。这一步不能阻止建号，但能大幅缩短从建号到被发现的时间窗。

第四步，做一次全量账号审计，把所有高权限组成员逐个过一遍，核对注册时间和创建来源。这一步在任何加固动作之前做，因为你不确定之前有没有已经被塞进去的账号。

4.3 事后排查：怎么确认站点被利用过

排查分三条线走，缺一条都可能漏。

账号线：拉高权限组成员列表，按注册时间排序，重点看最近三个月内新增的、邮箱明显异常的、用户名符合批量生成规律的记录。同时对比用户表里注册时间与最后访问时间的差值，正常用户注册后多少会登录，被塞进去的账号往往注册完就再也不动。

日志线：按注册任务入口筛访问日志，看有没有请求体里带数组字段的提交，看来源地址是否集中，看请求时间是否成串出现。日志保留周期短的站点要抓紧，很多托管环境的访问日志只留七天。

文件线：这一步容易被跳过但很重要。拿到高权限账号后，攻击者的下一步通常是改模板文件或装插件，在站点目录里留下入口文件。排查时按修改时间筛站点根目录和模板目录，重点看近期被改动、内容里含编码混淆的可疑文件。

# 按修改时间筛出近30天被改动的脚本文件，用于人工复核 find /path/to/site -type f -name "*.php" -mtime -30 -printf "%TY-%Tm-%Td %TH:%TM %p\n" | sort -r | head -50

跑完这条命令拿到的列表不要直接删，先逐个打开看内容。误删模板文件导致的故障，恢复成本比排查本身还高。

5. 排查技巧与常见问题实录

5.1 复现和排查中最常踩的五个坑

坑一：版本号看错。站点根目录的版本声明文件可以被二次开发改掉，也可能因为覆盖升级残留旧文件。判断实际版本要看用户表结构、看核心文件里的版本常量、看后台登录页的版本标识，三处交叉确认。我见过声明文件写 3.6.4 但核心文件还是 3.6.3 的站点，这种“假升级”在手工替换文件的场景里很常见。

坑二：组 ID 记死。默认安装是 7 和 8，但有插件会重建组，ID 就变了。所有 SQL 里的 ID 都必须现查现用。排查脚本里硬编码 ID 是最常见的错误来源。

坑三：只关注册不验证。后台点了关闭就以为安全了，没有实际发一次请求验证。8870 影响的版本上，关了注册请求依然能走通，所以“关”这个动作必须配合“验”。

坑四：只看前台不看调度器。有些站点通过计划任务或接口触发用户创建，入口不在前台注册页。排查时要把所有调用用户创建逻辑的入口都列出来，而不是只盯着注册页。

坑五：忘记清理测试账号。实验环境里造的账号忘了删，迁移数据库时带到了预发环境，后来被当成真实账号排查了半天。实验做完的第一件事就是恢复基线快照。

5.2 常见现象与成因速查

这张表建议打印出来贴在工位上，处理老站应急的时候按行对照，比临时想思路快得多。表里最值得关注的是第三行，补丁打了但行为没变，说明改动被覆盖，这种情况在做过深度二开的站点上占比不低。

5.3 我自己的几条实操心得

第一条，先做基线再做验证。任何实验之前先导快照，任何排查之前先备份数据库。这不是流程洁癖，是真的能省时间。数据被改动之后再想还原“原始状态”，成本高得多。

第二条，用 diff 思维代替记忆。不要试图记住某个版本的具体代码长什么样，直接把可疑站点的核心文件与同版本官方发布包做目录级 diff，差异文件就是二开点，二开点就是风险点。这个习惯比背漏洞细节有用十倍。

第三条，修完之后要回归验证。补丁生效不等于业务正常。升级或改代码之后，至少验证四件事：前台注册流程能走通（如果业务需要）、后台新建用户正常、用户组分配正确、原有账号能正常登录。我见过改完之后所有新用户都进不了任何组的情况，原因是默认组 ID 被写成了不存在的值，站点表面正常，实际所有新注册用户都是“无组”状态，权限全丢。

提示：默认新用户组的配置项一定要填真实存在的组 ID，改完立刻用一个测试账号验证权限，别等业务方反馈才发现。

这套分析思路往后还能往两个方向延展：一是拿同一时期的其他组件漏洞做横向对比，看表单白名单这个模式在别处有没有类似误用；二是把这里的排查清单整理成资产巡检脚本，定期跑一遍高权限组成员数和注册时间分布，发现异常自动告警。我在实际运维里用的是后者，脚本不长，但帮我提前发现过两次批量注册的苗头，比等安全设备告警快半天。