1. 项目概述从“模拟”到“提权”的实战路径在漏洞赏金猎人的世界里提权漏洞始终是皇冠上的明珠。它意味着从一个受限的账户权限跃升到系统管理员级别的控制权其价值不言而喻。今天要聊的这个案例源自一个真实的Bugcrowd项目核心思路非常巧妙通过应用程序内置的“模拟”功能实现权限提升。这听起来有点抽象简单来说就是利用一个原本设计用于“扮演”其他用户身份进行操作的合法功能绕过权限检查最终拿到系统最高权限。很多Web应用尤其是企业级或协作平台为了实现诸如“管理员代用户提交工单”、“上级审批时代下级操作”等场景会开发“模拟”功能。这个功能的本意是提升效率但如果授权逻辑存在缺陷就可能成为攻击者手中的利器。我这次遇到的正是这样一个靶标。整个过程没有依赖复杂的缓冲区溢出或内存破坏纯粹是逻辑层面的攻防考验的是对业务流、权限模型和会话机制的深度理解。对于刚入门SRC安全应急响应中心漏洞挖掘的朋友来说这类逻辑漏洞的挖掘思路和验证方法往往比二进制漏洞更具普适性和启发性。2. 漏洞原理深度解析模拟功能的信任边界在哪里要理解这个漏洞我们得先拆解“模拟”功能在典型Web应用中的实现逻辑。一个健壮的模拟功能其信任边界应该非常清晰通常包含以下几个关键检查点身份验证与授权当前用户必须有明确的权限如“模拟用户”权限才能发起模拟请求。目标用户限制通常只能模拟权限低于或等于自己的用户例如管理员可以模拟普通用户但普通用户不能模拟管理员。会话隔离与标识模拟开始后服务器会创建一个新的、临时的会话标识并与被模拟用户的身份绑定同时记录原始用户信息以便恢复。操作审计所有在模拟状态下执行的操作都需要记录原始操作者以备审计。漏洞产生的根源往往在于上述一个或多个检查点的缺失或逻辑谬误。在我分析的案例中问题核心出在第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(idtarget_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_usercurrent_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 信息收集与功能点梳理首先我以普通注册用户的身份登录系统。爬取与枚举使用浏览器手动浏览配合Burp Suite的爬虫功能尽可能遍历所有可见的功能链接和API端点。重点关注用户设置、管理员面板即使无法访问也要记录URL、个人资料编辑等区域。关键词搜索在HTTP历史记录中搜索“impersonate”、“su”、“switchuser”、“actas”、“模拟”、“切换”等关键词。同时在前端JavaScript文件中搜索相关函数调用和API路径。权限差异分析如果有多个测试账户不同角色对比它们的功能菜单和API响应差异。某个只有管理员可见的“用户管理”页面里很可能藏着“模拟用户”的按钮。在这个案例中我是在浏览一个“用户管理”仅列出部分基础信息的页面时通过查看页面源代码发现了一个被注释掉或通过CSS隐藏的HTML元素一个>