1. 项目概述：从“越界”到“失控”的权限迷宫

在Web应用安全的世界里，权限控制是守护数据与功能的第一道，也是最重要的一道防线。想象一下，你住在一栋公寓楼里，你的钥匙只能打开自己家的门（正常权限）。但有一天，你发现用这把钥匙不仅能开自己家的门，还能打开邻居家的门（水平越权），甚至能打开物业经理的办公室，查看整栋楼的监控和住户信息（垂直越权）。这种“钥匙”的失控，就是越权漏洞最直观的体现。

我从事渗透测试工作多年，越权漏洞（Broken Access Control）是实战中出现频率最高、危害性极大，却又常常被开发者忽视的一类安全问题。它不像SQL注入或XSS那样有炫酷的攻击载荷，其本质是业务逻辑的缺陷，攻击者通过构造非预期的请求，绕过系统设计的权限检查，执行本不该被允许的操作。根据OWASP Top 10，失效的访问控制常年位居高危漏洞前列。本次我们将深入拆解越权漏洞的两大核心类型：水平越权（Horizontal Privilege Escalation）和垂直越权（Vertical Privilege Escalation）。理解并掌握它们的原理、测试方法与修复思路，不仅是渗透测试工程师的必修课，也是每一位后端开发、架构设计人员必须绷紧的安全弦。

简单来说，水平越权是指攻击者访问到了与其拥有相同权限级别的其他用户的资源。例如，用户A通过修改请求中的用户ID参数，看到了用户B的订单、邮件或个人信息。垂直越权则更为严重，它指攻击者获取了更高权限角色的功能，例如一个普通用户通过某种方式执行了管理员才能进行的用户删除、配置修改等操作。无论是哪种，其后果都可能导致数据泄露、业务功能被恶意滥用，甚至整个系统沦陷。

2. 漏洞原理深度剖析：权限体系的“阿喀琉斯之踵”

要理解越权，必须先理解现代Web应用常见的权限控制模型。最主流的是基于角色的访问控制（RBAC）。系统会为每个用户分配一个或多个角色（如：游客、普通用户、VIP用户、管理员），每个角色拥有一组预设的权限。当用户发起请求时，后端逻辑会检查：“当前登录用户的角色，是否被允许执行这个操作？”

越权漏洞就发生在这个检查环节的失效。这种失效不是单一的，而是渗透在代码、设计和流程的多个层面。

2.1 水平越权：同层级的“串门”

水平越权的根源在于，应用程序在处理对“对象”的访问时，过度依赖客户端提供的信息来标识目标对象，而没有在服务端进行二次、强制的所属权校验。

典型缺陷模式：

1. 基于标识符的直接对象引用（IDOR）：这是水平越权最常见的形式。应用程序使用直接、可预测的标识符（如顺序数字ID：user_id=123，或用户名：username=alice）来访问数据库中的对象。攻击者只需修改这个ID，就能访问其他用户的同类数据。

   • 请求示例：GET /api/orders/1001查看自己的订单。将1001改为1002，成功看到了别人的订单。
   • 深层原因：后端代码可能只验证了用户是否登录（session.isAuthenticated()），但没有验证order_id=1002这条记录是否属于当前登录的用户（order.user_id == current_user.id）。

2. 不安全的直接对象引用变种：标识符可能隐藏在JSON参数、Cookie甚至文件名中。例如，文件下载接口GET /download?file=user_123_report.pdf，修改文件名即可下载他人文件。

3. 基于参数的横向访问：某些操作本身不需要对象ID，但需要通过其他参数来限定范围。例如，一个“查询我的消息”的接口，如果后端没有将查询范围与当前用户绑定，攻击者可能通过添加参数获取所有人的消息概要。

注意：水平越权不仅限于“读”操作（信息泄露），同样包括“写”操作（修改、删除）。例如，修改POST /api/address/update请求中的address_id参数，可能导致修改或删除他人的收货地址。

2.2 垂直越权：僭越层级的“夺权”

垂直越权的危害性更大，它意味着权限体系的整体崩塌。其核心是用户能够访问到其角色权限矩阵之外的功能或接口。

典型缺陷模式：

1. 界面隐藏而非服务端禁用：这是最经典的错误。管理员功能的前端按钮/菜单对普通用户是隐藏的（通过CSSdisplay:none或前端逻辑判断），但对应的API接口（如/api/admin/deleteUser）仍然对全网暴露，且服务端没有进行角色校验。攻击者通过抓包工具直接构造请求即可调用。

2. 脆弱的路径或功能名防护：应用程序通过URL路径（如/admin/）、路由名称或功能键值（function=delete_user）来区分权限。校验逻辑可能放在一个统一的入口过滤器（Filter）或中间件（Middleware）中，但如果存在校验遗漏、通配符错误或配置不当，攻击者就能找到“后门”。例如，过滤器只检查了/admin/*，但管理员实际功能分布在/manage/*和/console/*下。

3. 权限继承或提升逻辑缺陷：在某些复杂业务中，权限可能动态变化。例如，通过完成某个任务获得临时高级权限。如果权限提升的逻辑存在缺陷（如仅在前端标记，未在服务端令牌或会话中更新），或权限回收不及时，就会导致垂直越权。

4. 平行权限混淆为垂直越权：有时，系统存在多个平行的高权限角色，如“内容管理员”和“用户管理员”。如果校验逻辑只检查了“是否管理员”，而没有细分是“哪种管理员”，那么一个内容管理员可能越权执行用户管理的操作，这也是一种特殊的垂直越权。

根本原因总结：无论是水平还是垂直越权，其根源都在于“服务端信任了客户端传来的、关于‘谁有权做什么’的判断依据”。这个依据可能是用户ID、角色标识、功能键，而服务端没有用自己的会话信息、数据库查询结果对其进行强制、不可绕过的二次验证。

3. 实战测试方法论：从黑盒探测到逻辑推演

发现越权漏洞，需要测试人员兼具“黑客”的思维和“侦探”的细致。测试过程通常分为信息收集、漏洞探测、深度利用三个环节。以下是我在实战中总结的一套方法。

3.1 测试环境与工具准备

工欲善其事，必先利其器。越权测试对工具的要求相对灵活，核心是能拦截、修改和重放HTTP请求。

1. 核心工具：代理抓包工具

   • Burp Suite Professional/Community：行业标准，不可或缺。其Proxy、Repeater、Intruder模块是测试越权的利器。Scanner模块也能辅助发现一些明显的IDOR。
   • OWASP ZAP：开源免费，功能强大，是Burp Suite的优秀替代品。
   • 浏览器开发者工具（F12）：用于快速查看网络请求、分析前端代码逻辑，寻找隐藏的API端点或参数。

2. 辅助工具与环境

   • 至少两个测试账户：这是测试水平越权的基石。你需要准备同权限级别的账户A和B（如两个普通用户）。对于垂直越权，则需要一个低权限账户（如普通用户）和一个高权限账户（如管理员）。切勿在生产环境使用真实用户数据进行测试！
   • 浏览器多用户/无痕模式：方便同时登录多个账户，避免会话（Cookie）冲突。
   • 笔记工具：系统性地记录所有测试的端点、参数、请求/响应样本，这对于复杂应用的逻辑梳理至关重要。

3.2 水平越权测试步骤详解

水平越权的测试思路是：以用户A的身份操作对象A，捕获请求；然后保持登录状态（或使用用户A的会话），修改请求中指向对象A的标识符，尝试访问对象B；观察响应。

步骤一：枚举目标对象与参数

1. 使用账户A登录，遍历所有涉及个人数据的页面：用户中心、我的订单、我的消息、收货地址、上传的文件列表等。
2. 使用Burp Suite代理，拦截每一个操作产生的HTTP请求。重点关注：
   • URL路径中的ID：/user/123/profile,/order/456/detail。
   • 请求参数（GET/POST）中的ID：?id=789,{"document_id": "101112"}。
   • 自定义请求头中的ID：虽然不常见，但也要留意。
   • 不明显的标识符：如文件名、订单号、手机号、邮箱等。

步骤二：标识符修改与测试

1. 在Burp Suite的Repeater模块中，将捕获到的请求发送过去。
2. 修改疑似标识符的参数值。如何获取“对象B”的标识符？
   • 顺序推测：如果ID是数字，尝试+1或-1。
   • 从其他渠道获取：如果系统其他地方泄露了其他用户的ID（如论坛发帖显示作者ID），直接使用。
   • 使用账户B执行相同操作：用账户B登录，执行“查看我的订单”操作，捕获其订单ID。然后切换回账户A的会话（或Burp的Repeater标签页），用账户A的会话尝试访问账户B的这个订单ID。
3. 发送修改后的请求，分析响应。
   • 成功迹象（200 OK）：返回了其他用户的数据（HTML页面、JSON数据）。
   • 失败迹象：返回403 Forbidden、404 Not Found，或通用的错误信息“无权访问”。注意：返回404有时是一种安全设计（防止攻击者探测数据是否存在），但有时也意味着ID不属于当前用户，需要结合业务逻辑判断。

步骤三：测试写操作（增删改）水平越权不仅限于“看”，更要测试“改”。流程类似：

1. 用账户A修改自己的个人信息（如昵称），捕获POST /api/user/update请求，其中包含user_id: A_id。
2. 在Repeater中，将user_id修改为B_id，其他数据（如昵称）也做相应修改，发送请求。
3. 检查响应是否成功，并登录账户B验证其信息是否被账户A篡改。

实操心得：测试写操作时，务必小心！最好在测试环境进行。如果只能在准生产环境，修改的数据应是无害的，例如将别人的昵称改为“TestByHacker”，并在测试后立即修复。同时，要关注业务响应。有些接口可能返回“成功”，但实际数据库并未更新（可能后端有隐性校验），需要从多个角度验证。

3.3 垂直越权测试步骤详解

垂直越权的测试思路是：以低权限用户身份，尝试直接访问或调用仅限高权限用户使用的功能端点或参数。

步骤一：发现高权限功能端点

1. 前端代码分析：以低权限用户登录，打开浏览器开发者工具，查看源代码、JS文件以及网络请求。寻找那些被注释掉、被CSS隐藏（style="display:none"）或通过前端JS逻辑判断不渲染的管理员功能按钮/链接。这些元素对应的onclick事件或href链接，往往就是API端点。
2. 爬虫与目录扫描：使用Burp Suite的Target -> Site map功能，或者使用gobuster、dirsearch等工具，对网站目录进行扫描，寻找像/admin/,/manage/,/console/,/backend/这样的常见管理路径。即使返回403，也说明路径存在，值得深入。
3. 参考文档与错误信息：有时API文档、Robots.txt文件或调试模式的错误信息会泄露后端接口路径。

步骤二：绕过前端限制直接调用

1. 一旦发现疑似的高权限端点（如/api/admin/user/list），立即在Burp Suite的Repeater中，使用低权限用户的会话，构造一个访问该端点的请求。
   • 方法通常是简单的GET请求。
   • 如果是功能操作，可能需要模仿一个正常的POST请求，参数可以从高权限账户的请求中推测或捕获。
2. 发送请求，观察响应。
   • 最严重的情况：返回200 OK，并成功返回数据或执行了操作。
   • 常见情况：返回403 Forbidden（明确拒绝）。这通常是服务端做了校验。
   • 需要警惕的情况：返回302重定向到登录页，或返回401 Unauthorized。这可能意味着会话失效，或者端点存在额外的认证层。但有时重定向逻辑有误，可能仍存在绕过可能。

步骤三：测试参数越权有些接口本身是低权限用户可访问的，但通过传递不同的参数值，能触发高权限功能。

1. 捕获一个低权限用户的可执行操作请求，例如普通用户修改自己的资料：POST /api/user/update {“role”: “user”, “name”: “xxx”}。
2. 尝试修改参数，例如将"role": "user"改为"role": "administrator"，发送请求。
3. 检查响应，并查看自己的用户信息是否真的被提升为管理员。这就是一个通过参数实现的垂直越权。

4. 漏洞挖掘进阶技巧与案例分析

掌握了基础方法，就像学会了剑招。但要成为高手，还需要内功心法——即对业务逻辑的深刻理解和创造性的测试思维。

4.1 水平越权进阶：标识符的“化妆术”

现代应用为了安全，可能会避免使用简单的自增ID。测试人员需要识别各种“变形”的标识符。

1. GUID/UUID：看起来是550e8400-e29b-41d4-a716-446655440000这样的随机字符串。虽然不可预测，但如果低权限用户能在其他地方获取到高权限对象的GUID（例如，通过分享功能得到一个只读链接，其中包含了GUID），那么他仍然可以尝试用这个GUID去访问其他接口（如编辑接口），造成水平越权。关键在于GUID是否在用户间不恰当地暴露。
2. 哈希或加密ID：如id=md5(user_id+盐)。如果算法和盐值不变，且攻击者知道自己的user_id和对应的哈希ID，他就有可能推算出其他用户的user_id与哈希ID的映射关系，或者通过暴力枚举（如果user_id是数字）来测试。
3. 文件名与目录遍历：/download?file=../../other_user/private.txt。这结合了路径遍历和水平越权，需要检查服务端是否严格限制了文件访问范围。

案例：基于时间戳或顺序号的间接IDOR一个博客平台，查看文章的URL是/post/20231015_abc123，其中20231015是日期，abc123是随机码。但文章列表API返回的数据里，却包含了一个纯数字的internal_id: 1024。测试发现，直接访问/api/post/raw/1024可以获取文章的原始编辑数据（Markdown格式），而这个接口没有校验文章归属。通过遍历internal_id，可以窃取所有用户的文章草稿。

4.2 垂直越权进阶：逻辑链条的断裂点

垂直越权不一定发生在明显的“管理员”功能上，任何超出当前角色预设能力的操作都算。

1. 状态机越权：很多业务有状态流转，如订单状态：待支付->已支付->发货中->已完成。如果服务端没有严格校验状态变更的前置条件，普通用户可能通过调用“发货”接口，将自己的订单状态直接改为“已完成”，从而无需支付就获得商品。
2. 多阶段流程中的权限校验遗漏：一个申请流程，步骤一（填写信息）和步骤二（上传附件）都有权限校验，但步骤三（提交审核）的接口忘了校验，导致低权限用户可以直接调用步骤三接口，跳过前置条件完成申请。
3. API接口版本控制混乱：/api/v1/user/me（需要登录）和/api/v2/admin/users（需要管理员权限）可能共用了一套认证中间件，但v2的某个管理员接口错误地配置成了只验证登录，未验证角色。

案例：通过“忘记密码”功能提升权限一个系统的“忘记密码”功能流程是：输入邮箱->发送重置链接（含token）->通过链接设置新密码。重置链接形如/reset-password?token=xxx。测试发现：

1. 为低权限用户A申请重置密码，获得tokenA。
2. 用浏览器访问/reset-password?token=tokenA，打开重置页面。
3. 在Burp中拦截提交新密码的POST请求。此时，将请求中的email参数从userA@example.com改为admin@example.com。
4. 发送请求。如果后端仅通过token来识别重置目标，而没有在最后提交步骤再次绑定token与邮箱，那么攻击者就成功修改了管理员的密码，实现了垂直越权。

4.3 工具的高效运用：Burp Suite Intruder与Scanner

• Burp Intruder用于模糊测试：当发现一个疑似存在IDOR的接口（如/api/document/{id}），可以使用Intruder的“Sniper”模式，对{id}参数进行数字或字典爆破，快速筛选出哪些ID是可访问的（返回200），哪些是不可访问的（返回403/404）。这比手动修改效率高得多。
• Burp Scanner的辅助作用：Burp的主动扫描器有时能发现简单的IDOR漏洞，但它主要依赖于模式识别。对于复杂的业务逻辑越权，它无能为力。切勿依赖自动化工具，它们只是辅助，核心还是手动测试与逻辑分析。

5. 修复方案与安全开发建议

发现漏洞是第一步，如何修复和预防才是根本。作为测试人员，在报告中提供具体、可操作的修复建议，能极大提升你的专业价值。

5.1 根本性修复原则

1. 最小权限原则：每个用户、进程或程序只应拥有完成其任务所必需的最小权限。
2. 服务端强制校验：所有权限校验必须在服务端进行，且不可绕过。前端隐藏、禁用只是用户体验，不是安全措施。
3. 不可信客户端输入：永远不要信任客户端传来的任何关于权限或身份的信息（用户ID、角色、状态）。服务端必须从可信源（如会话Session、认证令牌JWT的解码结果）重新获取当前用户身份，并以此为基础进行校验。

5.2 水平越权修复方案

方案：基于所属权的访问控制在每一个需要访问具体数据对象的业务逻辑层（通常是Service层）或数据访问层（DAO层），在执行操作前，增加一道所属权检查。

// 伪代码示例：在查询或更新前，先验证归属 public Order getOrderById(Long orderId, Long currentUserId) { Order order = orderRepository.findById(orderId); if (order == null) { throw new NotFoundException("订单不存在"); } // 强制所属权校验 if (!order.getUserId().equals(currentUserId)) { throw new AccessDeniedException("无权访问此订单"); } return order; }

最佳实践：

• 使用统一的访问控制层：例如，在Spring框架中，可以使用@PreAuthorize注解结合SpEL表达式，如@PreAuthorize("@securityService.canAccessOrder(#orderId)")，将校验逻辑集中管理。
• 避免直接暴露数据库主键：对外接口可以使用无规律的、业务相关的唯一标识符（如订单号），并在内部建立与主键的映射关系，增加攻击者猜测的难度。
• 对列表查询进行过滤：查询“我的订单”时，SQL语句中必须包含WHERE user_id = :currentUserId条件，而不是先查出所有再在前端过滤。

5.3 垂直越权修复方案

方案：基于角色的访问控制（RBAC）与权限注解

1. 明确定义角色与权限：在系统设计阶段就清晰定义角色（Role）和权限（Permission）。一个角色是一组权限的集合。
2. 在接口入口处进行角色/权限校验：
   • 注解式（推荐）：在Controller的类或方法上使用声明式注解。

     @RestController @RequestMapping("/api/admin") @PreAuthorize("hasRole('ADMIN')") // 整个控制器都需要管理员角色 public class AdminController { @DeleteMapping("/user/{id}") @PreAuthorize("hasAuthority('USER_DELETE')") // 更细粒度的权限控制 public void deleteUser(@PathVariable Long id) { ... } }

   • 编程式：在方法内部进行判断。

     if (!currentUser.hasRole("ADMIN")) { throw new AccessDeniedException("需要管理员权限"); }

3. 保护管理端点：将管理后台部署在独立的子域名或路径，并通过网络层（如防火墙规则、WAF）或应用层（中间件）进行IP白名单或二次认证等额外保护。
4. 定期审计与测试：建立权限矩阵表，定期进行交叉检查。在新功能上线前，必须进行越权测试。

5.4 安全开发生命周期（SDLC）集成

将访问控制检查作为代码审查（Code Review）的必查项。在需求设计和架构评审阶段，就明确每个功能的访问控制要求。自动化安全测试（SAST/DAST）工具可以集成到CI/CD流水线中，捕捉一些常见的模式缺陷。

6. 常见问题排查与防御误区实录

在实际开发和测试中，会遇到很多似是而非的情况和常见的错误认知。

6.1 常见问题速查表

6.2 典型防御误区与陷阱

1. 误区一：“我们用了GUID，所以很安全”：如前所述，GUID防的是顺序枚举，但如果GUID被泄露（通过分享、引用等），越权依然存在。安全的核心是校验，不是混淆。
2. 误区二：“我们在网关层统一做了权限校验”：网关或统一鉴权中心是好的实践，但必须确保覆盖所有流量，且规则配置正确。微服务架构下，内部服务间的调用（如Service A调用Service B的管理接口）也可能绕过网关，需要在每个服务内部也实施防御（“零信任”原则）。
3. 误区三：“这个功能只有管理员在前端能看到，所以没问题”：这是最经典、最危险的错误。安全必须建立在“默认拒绝”的基础上，即除非显式允许，否则一律拒绝。前端展示逻辑与后端权限控制必须完全分离。
4. 误区四：“我们验证了用户会话，所以不会越权”：验证了用户是谁（认证），不等于验证了用户能做什么（授权）。这是认证（Authentication）和授权（Authorization）的根本区别，必须分开处理。
5. 陷阱：缓存导致的权限残留：用户从管理员降级为普通用户后，如果其浏览器或客户端缓存了之前的管理员功能菜单/数据，而服务端接口又恰好存在垂直越权，风险就会被放大。服务端应在权限变更时，使客户端相关的缓存失效。

渗透测试中对越权漏洞的挖掘，是一场与开发者思维定式的博弈。它要求测试者不仅会使用工具，更要理解业务，像攻击者一样思考，像设计者一样审视全局。每一次成功的越权测试，都是在为系统的安全壁垒添砖加瓦。记住，没有百分之百的安全，但通过严谨的设计、彻底的测试和持续的监控，我们可以让越权这扇“后门”牢牢锁上。在实战中，我习惯在测试完成后，不仅提交漏洞报告，还会附上一段简短的、针对该漏洞的修复代码样例或配置建议，这能让开发团队更快速地理解和解决问题，这也是专业性的体现。