Web应用模拟功能权限提升漏洞：从逻辑旁路到会话混淆的实战分析

1. 项目概述：从“模拟”到“提权”的实战路径

在漏洞赏金猎人的世界里，提权漏洞始终是皇冠上的明珠。它意味着从一个受限的账户权限，跃升到系统管理员级别的控制权，其价值不言而喻。今天要聊的这个案例，源自一个真实的Bugcrowd项目，核心思路非常巧妙：通过应用程序内置的“模拟”功能，实现权限提升。这听起来有点抽象，简单来说，就是利用一个原本设计用于“扮演”其他用户身份进行操作的合法功能，绕过权限检查，最终拿到系统最高权限。

很多Web应用，尤其是企业级或协作平台，为了实现诸如“管理员代用户提交工单”、“上级审批时代下级操作”等场景，会开发“模拟”功能。这个功能的本意是提升效率，但如果授权逻辑存在缺陷，就可能成为攻击者手中的利器。我这次遇到的正是这样一个靶标。整个过程没有依赖复杂的缓冲区溢出或内存破坏，纯粹是逻辑层面的攻防，考验的是对业务流、权限模型和会话机制的深度理解。对于刚入门SRC（安全应急响应中心）漏洞挖掘的朋友来说，这类逻辑漏洞的挖掘思路和验证方法，往往比二进制漏洞更具普适性和启发性。

2. 漏洞原理深度解析：模拟功能的信任边界在哪里？

要理解这个漏洞，我们得先拆解“模拟”功能在典型Web应用中的实现逻辑。一个健壮的模拟功能，其信任边界应该非常清晰，通常包含以下几个关键检查点：

1. 身份验证与授权：当前用户必须有明确的权限（如“模拟用户”权限）才能发起模拟请求。
2. 目标用户限制：通常只能模拟权限低于或等于自己的用户（例如，管理员可以模拟普通用户，但普通用户不能模拟管理员）。
3. 会话隔离与标识：模拟开始后，服务器会创建一个新的、临时的会话标识，并与被模拟用户的身份绑定，同时记录原始用户信息以便恢复。
4. 操作审计：所有在模拟状态下执行的操作，都需要记录原始操作者，以备审计。

漏洞产生的根源，往往在于上述一个或多个检查点的缺失或逻辑谬误。在我分析的案例中，问题核心出在第2点和第3点。

2.1 权限校验的逻辑旁路

应用在前端界面中，对可模拟的用户列表进行了过滤，只显示当前用户有权限模拟的账户。这是一个典型的前端防护，但后端API/api/v1/impersonate在接收模拟请求时，其权限校验逻辑存在缺陷。伪代码逻辑最初可能是这样的：

def impersonate_user(request, target_user_id): current_user = request.user # 检查当前用户是否有模拟权限 if not current_user.has_perm('can_impersonate'): return error('Permission denied') # 获取目标用户对象 target_user = User.objects.get(id=target_user_id) # 检查目标用户是否在“可模拟列表”中（这里可能依赖前端传入的列表ID，而非重新校验） if target_user not in current_user.allowed_impersonate_list(): return error('Cannot impersonate this user') # 创建模拟会话 new_session = create_impersonated_session(target_user, original_user=current_user) return success(new_session_token)

问题在于allowed_impersonate_list()这个函数。它可能基于一个静态的角色列表（如“只能模拟角色为‘Employee’的用户”）或一个动态的、缓存的列表。攻击者通过拦截并修改HTTP请求，将target_user_id替换为管理员用户的ID。如果后端只是简单地验证这个ID对应的用户是否存在于某个预定义的“低权限角色组”中，而管理员账户可能因为配置疏忽也被包含在内，或者后端根本没有对目标用户的权限级别进行二次确认，那么校验就会绕过。

更隐蔽的一种情况是，校验依赖了请求中的另一个参数，如target_department_id，通过判断部门来间接确定权限，但攻击者可以同时修改target_user_id和target_department_id，使其保持一致但指向高权限用户，从而通过校验。

2.2 会话标识的混淆与继承

模拟功能启动后，应用通常会颁发一个新的会话令牌。关键在于，这个新会话的权限上下文是如何构建的？漏洞可能出现在这里：

• 权限继承错误：新会话正确地关联了被模拟用户的身份（如用户名、用户ID），但在加载权限时，却错误地从原始会话的缓存或全局变量中继承了原始用户（即攻击者）的权限列表。这导致了一个“缝合怪”会话：身份是目标用户，权限却是攻击者的高权限。
• 会话状态污染：模拟操作没有完全清理旧会话中与权限相关的服务器端状态（例如，存储在session对象或Redis中的用户角色标识）。当系统后续根据这些残留状态判断权限时，就会授予错误的访问级别。
• 令牌混淆攻击：模拟后返回的令牌，可能在某些API端点下被解释为原始高权限令牌，而在另一些端点下被解释为模拟的低权限令牌。如果攻击者能找到一处关键的高权限操作API，恰好错误地识别了该令牌，提权便成功了。

这种漏洞的本质是应用程序的状态机出现了混乱，没有在用户身份切换的边界清晰地重置所有安全相关的上下文。

3. 实战挖掘过程：从黑盒探测到逻辑验证

我的挖掘过程始于彻底的黑盒侦察。面对一个未知的目标，我遵循了以下步骤：

3.1 信息收集与功能点梳理

首先，我以普通注册用户的身份登录系统。

1. 爬取与枚举：使用浏览器手动浏览，配合Burp Suite的爬虫功能，尽可能遍历所有可见的功能链接和API端点。重点关注用户设置、管理员面板（即使无法访问也要记录URL）、个人资料编辑等区域。
2. 关键词搜索：在HTTP历史记录中搜索“impersonate”、“su”、“switchuser”、“actas”、“模拟”、“切换”等关键词。同时，在前端JavaScript文件中搜索相关函数调用和API路径。
3. 权限差异分析：如果有多个测试账户（不同角色），对比它们的功能菜单和API响应差异。某个只有管理员可见的“用户管理”页面里，很可能藏着“模拟用户”的按钮。

在这个案例中，我是在浏览一个“用户管理”（仅列出部分基础信息）的页面时，通过查看页面源代码，发现了一个被注释掉或通过CSS隐藏的HTML元素：一个>