未授权访问漏洞深度剖析:从原理到实战的任意用户创建漏洞复现
1. 项目概述一次典型的未授权用户创建漏洞深度剖析最近在梳理一些企业级应用系统的安全风险时我注意到了“易天智能eHR”这个系统。作为一款面向企业的人力资源管理软件它承载着员工信息、薪酬、考勤等核心敏感数据其安全性不言而喻。然而安全研究社区近期披露了一个关于其CreateUser接口的漏洞攻击者可以在未授权的情况下直接通过该接口添加任意用户甚至可能获得管理员权限。这无疑是一个高危漏洞其影响范围可能覆盖大量使用该系统的企业。今天我就结合自己的渗透测试经验对这个漏洞进行一次完整的复现与分析并深入探讨其背后的成因、危害以及在实际攻防演练中的利用思路。对于安全从业者而言理解这类漏洞的挖掘与利用过程是提升自身实战能力、更好地为企业构筑防御体系的关键一步。这个漏洞的本质是一个典型的“功能级访问控制缺失”Broken Function Level Access Control, BFLAC。简单来说就是系统在设计时没有对“创建用户”这个高权限功能进行严格的身份验证和权限校验导致本应只有管理员才能访问的接口暴露在了未认证或低权限用户面前。这就像一栋大楼总经理办公室创建用户功能的门没有上锁甚至没有门禁卡识别任何人都能推门而入一样危险。接下来我将从环境搭建、漏洞原理、利用过程到深度防御为你层层拆解。2. 漏洞环境搭建与核心原理探究2.1 目标系统与测试环境准备要进行漏洞复现首先需要一个目标环境。由于直接测试生产系统是非法且不道德的我们必须搭建一个本地或隔离的测试环境。对于“易天智能eHR”系统我们可以通过以下几种方式获取测试资产官方试用版或演示系统部分厂商会提供公开的演示环境或限时试用版这是最合规的来源。从可信渠道获取的历史版本安装包在确保不侵犯知识产权且仅用于安全研究的前提下可以寻找用于测试的旧版本安装包。使用虚拟机搭建模拟环境如果无法获得真实安装包可以基于漏洞描述在本地使用类似框架如Spring Boot MyBatis模拟一个存在相同逻辑缺陷的简易eHR系统用于理解漏洞原理。注意所有漏洞研究必须在合法、授权的环境中进行。未经授权对任何在线系统进行测试均属违法行为。本文所有操作均假设在已获得明确授权的内部测试环境或专为安全研究搭建的隔离靶场中进行。假设我们已经获得了一个易天智能eHR系统的测试安装包例如版本号v2.1.3。典型的部署流程如下基础环境Windows Server 2016/2019 或 Windows 10/11 专业版安装IIS服务器、.NET Framework相应版本如4.7、SQL Server数据库。部署步骤将安装包解压至IIS网站目录如C:\inetpub\wwwroot\eHR。在IIS管理器中添加网站指向该目录并配置应用程序池为对应.NET版本。运行安装向导通常包含数据库连接配置服务器地址、数据库名、用户名密码。系统会自动创建数据库表结构并初始化基础数据。完成安装后访问系统首页使用默认管理员账号如admin/admin123登录。搭建好环境后我们首先需要对系统进行初步的信息收集了解其整体架构。通过浏览器开发者工具F12查看网络请求我们可以初步判断这是一个基于ASP.NET.aspx后缀或Java.do/.action后缀的Web应用。观察其URL结构和参数有助于我们定位可能存在问题的功能模块。2.2 漏洞接口定位与原理深度解析漏洞的核心在于CreateUser功能。在人力资源系统中用户管理模块通常位于后台路径可能类似于/admin/userManage.aspx或通过API接口如/api/user/create提供服务。我们的目标是找到这个创建用户的具体请求端点。手动探测过程使用正常管理员账号登录系统。进入“用户管理”或“组织架构”模块尝试添加一个新用户。在添加操作进行时打开浏览器开发者工具的“网络”Network选项卡捕获发出的HTTP请求。记录下这个请求的详细信息请求URL、方法通常是POST、请求头特别是Cookie或Authorization、请求体Form Data或JSON。例如我们可能捕获到这样一个请求POST /api/User/Create HTTP/1.1 Host: test-ehr.example.com Content-Type: application/json Cookie: ASP.NET_SessionIdabc123; .AspNetCore.Authxyz789 { loginName: newuser, password: Passw0rd!, realName: 测试用户, departmentId: 1001, roleIds: [1, 2] }漏洞原理分析 这个请求在管理员会话下是正常工作的。漏洞的产生源于服务器端对/api/User/Create这个接口的访问控制逻辑存在缺陷。可能存在以下几种情况情况A接口未做任何权限校验。服务器端代码在处理该请求时完全没有检查请求是否来自已登录用户或者用户是否拥有“创建用户”的权限。这是最严重的情况。情况B权限校验依赖于前端隐藏或禁用。管理界面可能通过前端JS代码控制“添加用户”按钮的显示但对于直接构造请求到后端接口的行为后端没有进行二次校验。情况C权限校验逻辑存在绕过可能。例如校验了用户角色是否为“管理员”但角色ID可以从请求参数中篡改或者校验逻辑存在缺陷可以通过特定参数组合绕过。在本漏洞的典型场景中我们遇到的多是情况A。攻击者无需登录只需直接向这个接口发送构造好的POST请求服务器就会忠实地执行创建用户的操作并返回成功响应。这背后的根本原因是开发人员安全意识不足认为该接口只会被前端管理页面调用而管理页面本身有登录墙从而忽略了服务器端最根本的权限验证。3. 漏洞利用过程与实战复现理解了原理接下来就是实战环节。我们将一步步演示如何发现并利用这个漏洞。3.1 利用工具准备与请求构造我们不需要复杂的工具一个能发送HTTP请求的工具即可例如Burp Suite渗透测试首选强大的代理和重放功能。PostmanAPI测试工具图形化界面友好。cURL命令行工具轻量灵活。Python requests库适合编写自动化脚本。这里以Burp Suite为例进行演示配置代理打开Burp Suite在Proxy - Options中确保代理监听正确如127.0.0.1:8080。将浏览器代理设置为Burp。捕获管理员请求按照2.2节的方法用管理员账号完成一次正常的用户创建操作并在Burp的Proxy - HTTP history中捕获到这个POST /api/User/Create请求。发送到Repeater右键点击该请求选择“Send to Repeater”。在Repeater标签页中我们现在拥有了一份完整的、有效的创建用户请求模板。3.2 关键步骤移除身份凭证进行未授权测试这是验证漏洞是否存在的最关键一步。在Repeater中我们直接修改捕获到的请求删除身份标识将请求头中的Cookie或Authorization字段整个删除。这意味着我们模拟了一个完全没有登录会话的请求。修改请求体将loginName、realName等字段值改为我们想要创建的用户名例如hacker01。发送请求点击“Send”按钮。结果分析漏洞存在如果服务器返回了成功的状态码如200 OK并且响应体中包含“创建成功”或类似的字样甚至返回了新用户的ID那么漏洞就被确认了。这意味着任何人在任何地方只要知道这个接口地址就能给你的系统添加用户。漏洞不存在如果服务器返回了403 Forbidden禁止访问、401 Unauthorized未授权或跳转到登录页面则说明接口有基本的权限校验。假设我们收到了成功响应{ code: 200, message: 用户创建成功, data: { userId: 2024110001 } }这证实了漏洞确实存在且危害极高。3.3 漏洞利用的扩展尝试创建管理员用户仅仅创建普通用户可能还不够攻击者的最终目的往往是获取最高权限。因此我们需要探索是否能直接创建管理员用户。回顾我们捕获的请求体其中有一个关键字段roleIds: [1, 2]。这很可能代表了分配给新用户的角色ID。我们需要找出哪个角色ID对应着系统管理员。信息收集方法枚举与猜测在已登录的管理员会话中查看角色管理列表。通常超级管理员的ID可能是“1”或“0”。可以尝试在未授权请求中将roleIds设置为[1]。观察现有管理员在系统的用户列表或编辑用户信息界面查看现有管理员的详细信息看能否获取其角色ID。基于响应的推断如果创建用户时指定了某个角色ID系统返回成功之后我们可以用这个新账号尝试登录并访问只有管理员才能看到的功能如系统设置、日志管理来验证权限。构造一个创建管理员的请求体示例{ loginName: superadmin_hacker, password: Hck3rPss, realName: 系统管理员, departmentId: 1000, // 可能是总部或最高部门ID roleIds: [1] // 假设1是超级管理员角色 }发送这个未授权的请求。如果再次成功那么攻击者就完全掌控了系统可以查看所有员工敏感信息、篡改薪资数据、删除操作日志等造成灾难性后果。4. 漏洞挖掘方法论与常见问题排查4.1 如何系统性发现此类漏洞这个漏洞的发现并非偶然它遵循一套可复用的安全测试方法论功能点梳理拿到一个系统首先以普通用户和管理员身份完整走查所有功能列出所有可能涉及增删改查尤其是增和改的接口例如创建用户、修改订单、删除文章、上传文件等。这些是“功能级访问控制”测试的重点。接口枚举使用爬虫工具如Burp的爬虫、gobuster、dirsearch或通过分析前端JS代码尽可能全面地收集系统的API接口URL。权限越权测试这是核心步骤。对于每一个高权限功能接口如/api/xxx/create,/api/xxx/delete水平越权测试用A用户的身份去操作B用户的数据例如修改/api/order/update?id100而订单100属于用户B。垂直越权测试用低权限用户或未授权去访问高权限用户的接口。本文的漏洞就是典型的垂直越权。测试用例设计针对垂直越权测试用例非常简单在移除所有身份认证令牌Cookie/Token的情况下直接向高权限接口发送合法格式的请求。同时也要测试低权限用户如普通员工访问管理员接口的情况。4.2 复现过程中的常见问题与解决方案在实际复现过程中你可能会遇到以下问题问题现象可能原因排查思路与解决方案移除Cookie后返回403/401接口有基础的权限校验漏洞可能不存在或校验方式更复杂。尝试1. 使用低权限用户的Cookie。2. 检查是否有其他认证方式如JWT Token在请求头或参数中。3. 寻找该接口的其他调用路径或参数。请求返回“参数错误”或“验证失败”请求体格式或参数不全仔细比对管理员操作时捕获的原始请求确保JSON格式正确所有必需字段都已包含且值有效如departmentId必须是一个存在的部门ID。创建成功但用户无法登录密码加密方式或状态问题检查创建用户时密码是否以明文传输。如果是可能前端做了加密。需要分析前端JS找到加密算法在构造请求时模拟加密。或者新建的用户可能处于“禁用”状态需要再寻找“启用用户”的接口进行测试。找不到/api/User/Create接口接口路径不同或功能命名不同使用爬虫工具进行目录爆破。尝试常见路径如/user/add,/admin/userAdd.do,/servlet/UserCreate等。分析前端JS中网络请求的代码。系统使用了Token且无法轻易移除采用了如JWT等Token机制即使移除Cookie请求头中的Authorization: Bearer token仍是关键。需要测试1. 使用一个过期或无效的Token看服务器是否校验Token有效性。2. 如果Token可解码JWT查看其payload中是否包含权限信息如role: admin尝试篡改并重签需密钥或寻找Token生成/验证的逻辑漏洞。实操心得在测试时务必使用Burp Suite的“Compare”功能。将管理员成功请求和未授权测试请求的响应进行对比差异点往往能给你带来新的绕过思路。例如未授权请求返回了“角色不存在”那么可能只是roleIds参数不对而接口本身是可未授权访问的。5. 漏洞修复建议与安全开发规范对于企业开发和安全团队而言复现漏洞的最终目的是为了修复和预防。针对此类“任意用户添加”漏洞修复必须从根本的访问控制机制入手。5.1 立即修复方案后端强制权限校验在CreateUser接口的业务逻辑最开头加入统一的、服务端的权限检查代码。绝不能依赖前端控制或隐藏接口。代码示例ASP.NET Core 伪代码[HttpPost(api/User/Create)] [Authorize(Roles Administrator)] // 使用声明式角色授权 public IActionResult CreateUser([FromBody] UserCreateDto dto) { // 或者进行编程式校验 // if (!User.IsInRole(Administrator)) // { // return Forbid(); // 返回403 // } // ... 实际的创建用户逻辑 }关键点校验必须基于服务器端的会话或Token中的可信信息如用户ID、角色列表而不是客户端传来的任何参数。增加请求来源验证辅助措施可以验证请求是否来自预期的管理界面例如检查HTTP Referer头但可伪造不可单独依赖或为管理操作添加一次性TokenCSRF Token增加攻击复杂度。接口审计与监控立即在WAFWeb应用防火墙或应用层日志中对/api/User/Create等敏感接口的访问进行监控告警所有未授权或来自异常IP的访问尝试。5.2 根本性预防与安全开发规范要杜绝此类漏洞需要将安全思维融入开发全生命周期SDLC采用最小权限原则每个接口、每个功能都明确其所需的最小权限。在系统设计阶段就定义清晰的权限模型如RBAC-基于角色的访问控制。实施统一的访问控制层不要在每一个业务Controller里都写一遍权限判断代码。应使用框架提供的拦截器Interceptor、过滤器Filter或中间件Middleware实现统一的权限校验逻辑避免遗漏。例如Spring Security的PreAuthorize注解或定义一个自定义的权限校验AOP切面。定期进行代码安全审计将“未授权访问”作为代码审计的重点检查项。使用SAST静态应用安全测试工具扫描代码查找缺少权限注解或校验的敏感接口。加强渗透测试与红队演练定期对系统进行深度的渗透测试特别是“权限越权”测试应成为测试用例库的强制组成部分。模拟攻击者的思维尝试绕过前端直接与后端API交互。安全意识培训对开发人员进行持续的安全编码培训让他们深刻理解“永远不要信任客户端传来的任何数据”、“所有服务端接口都必须进行权限校验”等核心安全原则。这个“易天智能eHR CreateUser 任意用户添加漏洞”是一个教科书级别的反面案例它清晰地展示了忽略服务端权限校验所带来的巨大风险。对于安全研究人员掌握其复现方法能提升漏洞挖掘能力对于开发人员它是一次深刻的安全警示对于企业安全运维团队则是一次检查和加固自身系统的契机。安全是一个持续的过程而非一劳永逸的状态唯有将安全意识渗透到每一个功能、每一行代码中才能构建起真正稳固的防御体系。

相关新闻