从权限模型到数据泄露：深度剖析JumpServer超级令牌CVE-2025-62712的成因与影响
1. 从一个“模糊”的权限说起
大家好，我是老张，在运维安全这个圈子里摸爬滚打了十几年，见过不少因为权限设计“想当然”而引发的安全事件。最近，JumpServer爆出的这个CVE-2025-62712漏洞，可以说是一个教科书级别的案例。它不像那种复杂的逻辑漏洞或者内存溢出，它的根源简单得让人有点意外：一个权限的名字起得太“模糊”了，加上框架的“默认行为”，两者一结合，就捅出了能泄露所有用户连接令牌的大篓子。
咱们先抛开技术细节，打个比方。假设你是一家公司的仓库管理员，老板给了你一把钥匙，钥匙上贴的标签是“可以查看超级贵重物品”。这个标签很模糊，对吧？“超级贵重物品”具体指什么？是保险柜里的钻石，还是仓库里那批新到的电脑？你拿着这把钥匙，发现它能打开仓库里所有的门，包括那些存放着其他部门机密文件的柜子。问题就出在这里：标签（权限名）的模糊性，让你误以为自己只有查看某几样特定物品的权利，但实际上，你拿到了整个仓库的通行证。
CVE-2025-62712漏洞的核心，就是这个名为authentication.view_superconnectiontoken的权限。光看这个名字，“查看超级连接令牌”，你觉得它应该能干嘛？可能很多管理员，包括我早年也可能这么想：“哦，这个权限就是让有需要的人（比如审计员、值班运维）能查一下当前有效的超级令牌有哪些，方便 troubleshooting。” 基于这种理解，在配置用户角色时，就很自然地把这个权限赋予了非超级管理员但需要一定视野的角色。
但JumpServer的代码逻辑和Django REST Framework（DRF）的默认机制，却给了这个权限远超其名字含义的能力。这个权限不仅允许你“查看”，在特定接口下，它默认允许你执行list（列表查询）操作。而负责处理超级令牌列表查询的那个视图（SuperConnectionTokenViewSet），它的数据过滤方法（get_queryset）又写得“太实在”了，直接返回了数据库里所有的连接令牌，没有做任何基于当前用户的过滤。
于是，攻击链就清晰了：一个拥有authentication.view_superconnectiontoken权限的普通用户（可能是被误授权限的审计员账号，甚至是一个权限提升后的低权限用户），去访问/api/v1/authentication/super-connection-token/这个API端点。系统检查权限，通过；然后执行查询，返回全部数据。一瞬间，所有用户的敏感连接令牌，包括可能包含密码、密钥的secret字段，就全部泄露了。攻击者拿到这些令牌，可以直接冒充其他用户去连接后台服务器、数据库等核心资产，后果不堪设想。
这个漏洞给我的触动很大。它提醒我们，在设计和评审权限系统时，绝不能只看权限的名字“大概是什么意思”，必须深挖其背后在代码中实际控制的行为。尤其是当使用了像DRF这样高度封装、提供了很多“便利”默认行为的框架时，更要警惕这些“默认”可能带来的安全盲区。
2. 深入漏洞现场：权限模型与框架行为的错配
要真正理解这个漏洞，我们不能只停留在表面描述，得钻到代码层面，看看JumpServer的权限模型（RBAC）和Django REST Framework（DRF）是怎么“配合失误”的。我会尽量用大白话把这里面的门道讲清楚。
2.1 JumpServer的RBAC权限模型设计
JumpServer自己实现了一套基于角色的权限访问控制（RBAC）系统，和Django自带的权限系统结合使用。在这个模型里，权限最终会体现为一个字符串，叫做codename，格式是{应用名}.{动作}_{模型名}。比如，authentication.view_superconnectiontoken就表示在authentication这个应用里，对SuperConnectionToken这个模型有“查看（view）”的权限。
在编写一个API视图类（ViewSet）时，开发人员需要显式地定义每个“动作”（action）需要什么权限。这个定义放在一个叫rbac_perms的字典里。比如，你定义‘create’: ‘authentication.add_superconnectiontoken‘，意思就是，执行“创建”这个动作，用户必须拥有“添加超级令牌”的权限。
这里就出现了第一个关键点：如果某个动作没有在rbac_perms里显式定义，系统会怎么办？JumpServer的处理方式是：回退到使用默认权限。这个默认权限的codename就是按照{app_label}.view_{model_name}这个公式生成的。对于SuperConnectionToken模型，默认权限正好就是authentication.view_superconnectiontoken。
2.2 Django REST Framework的标准动作映射
DRF的ModelViewSet是一个非常方便的类，它默认提供了针对一个模型的一套完整增删改查（CRUD）操作。这些操作在内部被映射为一个个标准的“动作”。最重要的几个标准动作包括：
list: 对应GET /api/resource/，获取资源列表。retrieve: 对应GET /api/resource/{id}/，获取单个资源详情。create: 对应POST /api/resource/，创建新资源。update/partial_update: 对应PUT/PATCH /api/resource/{id}/，更新资源。destroy: 对应DELETE /api/resource/{id}/，删除资源。
当你在URL里注册了一个ViewSet，DRF的路由器会自动把这些HTTP方法和标准动作关联起来。访问GET /api/v1/authentication/super-connection-token/，DRF就会去找SuperConnectionTokenViewSet里的.list()方法。
2.3 危险的结合：缺失的显式声明
现在我们来看漏洞的核心文件connection_token.py里的SuperConnectionTokenViewSet类。在漏洞版本的代码中，它的rbac_perms是这样定义的：
rbac_perms = { 'create': 'authentication.add_superconnectiontoken', 'renewal': 'authentication.add_superconnectiontoken', 'check': 'authentication.view_superconnectiontoken', 'get_secret_detail': 'authentication.view_superconnectiontokensecret', 'get_applet_info': 'authentication.view_superconnectiontoken', 'release_applet_account': 'authentication.view_superconnectiontoken', 'get_virtual_app_info': 'authentication.view_superconnectiontoken', }你发现了什么？它定义了create、renewal、check等一堆自定义动作的权限，但偏偏没有定义两个最基础、最常用的标准动作：list和retrieve！
根据我们上面说的规则，当用户请求list（获取列表）时，由于rbac_perms里没有‘list‘这个键，权限系统就会回退到默认权限authentication.view_superconnectiontoken。只要用户有这个权限，请求就能通过校验。
2.4 最后一环：毫无过滤的数据查询
权限检查通过了，接下来就是执行.list()方法。.list()方法会调用.get_queryset()来获取要展示的数据集。我们看看有问题的SuperConnectionTokenViewSet是怎么实现这个方法的：
def get_queryset(self): return ConnectionToken.objects.all()简单粗暴的一句objects.all()，返回了数据库里所有的ConnectionToken记录，没有按当前登录用户 (self.request.user) 进行任何过滤。作为对比，它的父类ConnectionTokenViewSet（普通用户连接令牌视图）的实现就是安全的：
def get_queryset(self): queryset = ConnectionToken.objects \ .filter(user=self.request.user) \ .filter(date_expired__gt=timezone.now()) return queryset父类明确过滤了user为当前用户，并且只返回未过期的令牌。而超级令牌视图本意可能是给管理员一个全局视图，但它错误地依赖权限来限制访问，而权限又因为命名模糊和默认行为被错误地分配了出去。
整个攻击链的串联：模糊的权限名 -> 被误授予非管理员 -> 未显式定义list动作权限 -> 回退到默认权限（恰好是那个模糊权限）-> 权限校验通过 -> 执行未过滤的全局查询 (objects.all()) -> 全量数据泄露。一环扣一环，缺一不可，但偏偏就凑齐了。
3. 漏洞复现与影响深度分析
光讲原理可能还有点抽象，咱们动手模拟一下，看看这个漏洞在实际中是如何被触发和利用的，以及它到底能造成多严重的后果。我会带你走一遍从环境搭建到数据窃取的全过程，你可以把它看作一次在完全受控环境下的“攻防演练”。
3.1 搭建一个存在漏洞的JumpServer环境
为了安全研究，我们可以在本地虚拟机（比如Ubuntu 22.04）上快速搭建一个存在漏洞的JumpServer版本。这里以v4.10.10为例（请注意，仅用于合法安全测试）。
# 1. 进入常用安装目录 cd /opt # 2. 下载特定版本的安装包 sudo wget https://github.com/jumpserver/installer/releases/download/v4.10.10/jumpserver-installer-v4.10.10.tar.gz # 3. 解压并进入目录 sudo tar -xf jumpserver-installer-v4.10.10.tar.gz cd jumpserver-installer-v4.10.10 # 4. 执行安装脚本，这个过程会下载Docker镜像，需要一些时间 sudo ./jmsctl.sh install安装过程中，大部分配置可以直接回车用默认值。安装完成后，脚本会给出Web访问地址（通常是https://<你的IP>）和默认的超级管理员账号密码（admin/admin）。
# 5. 启动JumpServer服务 sudo ./jmsctl.sh start登录后台后，为了模拟真实场景，我们需要创建一些测试数据：
- 创建普通用户：在“用户管理”里创建一个新用户，比如叫
auditor（审计员）。 - 创建角色并授权：创建一个“审计员”角色，把
authentication.view_superconnectiontoken这个权限分配给它。然后把auditor用户归属到这个角色下。这一步是关键，模拟了权限被错误分配的场景。 - 创建资产和连接：用管理员账号创建一台测试Linux资产，并添加一个系统账号。然后让管理员或其他用户生成一个对该资产的“连接令牌”。
3.2 手动触发漏洞，见证数据泄露
现在，我们切换到auditor用户的视角。这个用户只有审计相关权限，理论上不应该看到别人的连接令牌。
- 登录获取会话：使用
auditor账号密码登录JumpServer的Web界面。登录成功后，浏览器会获得一个会话Cookie（通常是名为sessionid或jms-sessionid的Cookie）。这个Cookie是后续API请求的凭证。 - 构造API请求：我们不从Web界面操作，而是直接模拟攻击者调用API。打开浏览器的开发者工具（F12），切换到“网络(Network)”标签页。
- 发送恶意请求：在Console标签页，或者使用
curl命令，发送一个GET请求到漏洞端点：
或者，直接在浏览器地址栏里访问这个URL（需要已登录状态），你会在网络面板看到这个请求。# 使用 curl 示例 (需要替换你的 JumpServer 地址和 Cookie) curl -X GET 'https://<你的JumpServer-IP>/api/v1/authentication/super-connection-token/' \ -H 'Cookie: sessionid=<你的auditor用户的sessionid值>' \ -H 'Accept: application/json' \ -k # -k 参数忽略证书警告（如果用了自签名证书） - 查看泄露的数据：请求的响应会是一个JSON数组。你会震惊地发现，这个数组里包含了系统中所有用户生成的所有超级连接令牌！每条记录都可能有这些敏感字段：
id: 令牌唯一IDuser: 创建该令牌的用户信息（用户名、ID等）asset: 令牌所连接的资产信息（IP、主机名等）account: 连接所使用的账号名secret:最致命的字段，连接所需的密码或密钥（可能被加密存储，但拥有令牌即可直接使用）date_expired: 过期时间
这意味着什么？攻击者auditor拿到了管理员的连接令牌secret，他就可以完全绕过JumpServer的审计和授权，直接使用这个令牌去连接后台的核心服务器，比如数据库、跳板机、Kubernetes集群管理节点。所有操作都不会留下auditor本人的痕迹，因为他是“冒充”管理员在操作。
3.3 漏洞的潜在影响与攻击场景
这个漏洞的影响远不止“看到一些数据”那么简单，它打开了通往核心资产的秘密通道。
- 横向移动与权限提升：攻击者可以先利用一个低权限漏洞（比如一个简单的SQL注入或信息泄露）获取到一个拥有
authentication.view_superconnectiontoken权限的账号。然后通过本漏洞，窃取更高权限用户（如系统管理员、运维负责人）的连接令牌，瞬间完成权限飞跃。 - 绕过所有安全审计：JumpServer作为堡垒机，其核心价值之一是会话审计和操作录像。但通过窃取的令牌直接连接资产，这些连接不会经过JumpServer的正常会话管理流程，因此不会有命令记录、操作录像，实现了“隐身”攻击。
- 供应链攻击跳板：如果JumpServer管理着大量内部开发、测试或生产服务器，攻击者可以利用这些令牌渗透进软件供应链的各个环节，植入后门、窃取源码，影响面呈指数级扩大。
- 数据窃取与勒索：直接访问数据库服务器、文件服务器，导致大规模敏感数据（客户信息、财务数据、商业机密）泄露，甚至为勒索软件加密整个内网铺平道路。
我见过很多企业，堡垒机配置好了就觉得高枕无忧了。但这个漏洞告诉我们，堡垒机本身如果出现权限模型上的设计缺陷，它不但不是防线，反而会成为攻击者最锋利的矛。
4. 漏洞修复方案与深度防御思考
官方在接到报告后，迅速发布了修复补丁。我们通过分析补丁，不仅能学会如何修复这个特定漏洞，更能学到如何避免同类问题在自己的项目中发生。
4.1 官方修复方案剖析
修复的核心思路非常清晰，就是堵上我们前面分析的那两个缺口：
补上权限定义的漏洞：在
SuperConnectionTokenViewSet的rbac_perms字典中，显式地添加list和retrieve动作所需的权限。# 修复后的 rbac_perms (示例) rbac_perms = { 'list': 'authentication.view_superconnectiontoken', # 新增 'retrieve': 'authentication.view_superconnectiontoken', # 新增 'create': 'authentication.add_superconnectiontoken', # ... 其他动作保持不变 }这看起来好像没变？不，意义重大。虽然用的还是同一个权限字符串，但显式声明意味着这个权限现在明确关联到了
list/retrieve动作上。在权限评审时，安全人员或开发者看到authentication.view_superconnectiontoken被用于list，就会更容易意识到它可能带来全局数据访问的风险，从而更审慎地分配它。同时，这也符合“最小权限原则”中“明确权限范围”的要求。收紧数据查询范围（可选但更佳）：虽然仅修复权限可能已足够，但更健壮的做法是同时修改
get_queryset()方法。即使未来权限被错误分配，数据层面也有最后一道防线。可以参考父类或管理员视图的做法，加入过滤条件。例如，可以修改为只返回当前用户创建的、或与当前用户相关的超级令牌（如果业务逻辑允许）。
最直接有效的修复方式就是升级JumpServer到已修复该漏洞的安全版本。请务必关注JumpServer官方的安全公告，及时更新。
4.2 临时缓解措施
如果因为某些原因无法立即升级，可以考虑以下临时加固手段，为升级争取时间：
- 网络层拦截：在JumpServer前方的Web代理（如Nginx）上配置规则，拦截对危险端点的访问。
location /api/v1/authentication/super-connection-token/ { # 只允许POST方法（用于创建令牌），拒绝GET方法（列表查询） if ($request_method = GET) { return 403; } # 或者，更严格地，只允许来自管理后台IP的访问 # allow 10.0.0.0/8; # 管理网段 # allow 192.168.1.100; # 管理员固定IP # deny all; proxy_pass http://jumpserver_backend; } - 应用层权限复核：立即在JumpServer后台审计所有用户和角色，检查是否有非超级管理员角色被授予了
authentication.view_superconnectiontoken权限。如果有，立即移除，并评估其实际工作需要，授予更细粒度、更安全的权限。
4.3 给开发者的深度防御建议
这个漏洞是一次深刻的教训。我们在日常开发中，尤其是设计权限系统和API时，应该如何避免踩进同样的坑？
- 原则一：永远显式声明权限：在使用DRF等框架时，为你视图集中的每一个动作（action），包括
list、retrieve、create、update、destroy这些标准动作，都显式地在permission_classes或类似机制中声明所需的权限。不要依赖框架的任何“默认”权限行为，默认往往意味着“宽松”或“未定义”。 - 原则二：遵循最小权限原则：设计权限时，名称要尽可能精确地反映其实际控制的操作和数据范围。
view_superconnectiontoken这个名字就太宽泛了。可以考虑拆分为view_own_superconnectiontoken（查看自己的）、view_all_superconnectiontoken（查看所有）。后者应该只赋予极少数核心管理员。 - 原则三：视图层与数据层双重校验：权限检查是视图层（View）的责任，而数据过滤是模型层（Model）或查询集（QuerySet）的责任。两者不能互相替代。在
get_queryset()方法中，必须根据当前请求的用户（self.request.user）进行数据过滤。这是防止越权访问的最后一道，也是最可靠的防线。永远不要写Model.objects.all()而不加过滤。 - 原则四：定期进行权限审计与代码审查：将权限配置和视图的权限声明纳入代码审查的重点。定期运行自动化脚本，扫描项目中是否存在未显式声明权限的视图动作，或者
get_queryset中缺少用户过滤的查询。安全是一个持续的过程，不是一次性的设置。
在我经历过的项目中，很多严重的越权漏洞都源于“想当然”和“图省事”。认为“有这个权限的人应该都是可信的”，或者“框架默认会处理好”。CVE-2025-62712再次敲响了警钟：在安全面前，没有“应该”，只有“明确”和“验证”。每一次权限的分配，每一行数据查询的代码，都需要我们带着审慎和质疑的眼光去看待。