【Web安全】一次性搞懂越权漏洞原理/检测/防御_后端权限越界原理及防护-CSDN博客

本文链接：https://blog.csdn.net/qq_40037555/article/details/149372439

往期文章

前言

在网络安全的攻防语境中，几乎所有漏洞的本质都可归结为 “对系统权限边界的突破”—— 从缓冲区溢出到 SQL 注入，从 XSS 到 CSRF，其核心都是攻击者绕过了某种预设的权限限制。

但本文聚焦的 “越权漏洞”，特指网络安全领域中狭义的权限滥用场景：它不依赖复杂的代码执行或逻辑绕过，而是利用系统对 “用户身份与操作权限匹配性” 的校验缺陷，让攻击者以 “合法用户” 的身份，执行本不属于其权限范围的操作。这种漏洞因隐蔽性强、利用成本低，成为 Web 应用中最常见的 “权限后门”。

1 漏洞本质

越权漏洞（Broken Access Control）的核心是服务器对用户权限的校验逻辑失效，导致攻击者能以低于自身权限的账号访问高权限资源，或在同权限用户间非法访问彼此数据。

简单来说，就是"该拦的没拦住，不该看的被看了"。

2 攻击原理

在这里插入图片描述

攻击链路：
攻击者 → 发现权限可控参数（如role=user）→ 篡改参数尝试越权访问 → 服务器未校验 → 返回敏感数据 / 执行操作

3 漏洞场景

3.1 纵向越权（垂直越权）

低权限用户访问高权限功能（如普通用户执行管理员操作）。

典型场景：

后台地址暴露：管理员后台地址（如/admin）未做权限校验，普通用户直接访问即可进入。
参数篡改提权：通过修改请求中的权限标识（如isAdmin=false改为isAdmin=true），获取管理员操作权限。
功能点越权：支付系统中，普通用户调用/api/refund/confirm退款审批接口时，服务器未校验"该用户是否有退款审批权限"，导致随意发起大额退款。
修改返回包参数：通过修改返回包实现垂直越权的核心原因是：服务器端没有在 关键操作执行时 进行独立、动态的权限校验，而是过度信任客户端传递的数据。

正确的做法是：所有涉及权限的操作，必须在服务器端重新校验当前登录用户的真实权限（从数据库或服务器端会话中获取），完全不依赖客户端传递的任何权限标识。

3.2 横向越权

同级别用户间的权限滥用（如 A 用户访问 B 用户的订单）。

典型场景：

用户数据遍历：通过修改user_id、order_id等参数，遍历查询其他用户的个人信息、订单记录、聊天记录等。
操作劫持：修改请求中的目标ID，执行本应属于其他用户的操作（如修改他人密码、删除他人发布的内容）。
共享资源滥用：云存储平台中，同权限用户通过猜测资源ID（如图片id=xxx），访问他人上传的私有文件。

IDOR

这里单独提一下网络上常说的 IDOR：

根据 OWASP 的定义，不安全的直接对象引用（IDOR）是指当应用程序根据用户提供的输入提供对对象的直接访问时，未进行适当的权限验证而产生的安全漏洞

IDOR 实际就是越权的一种具体实现场景，是水平越权中最典型的场景，例如：

正常请求：/api/order?user_id=123（用户 A 查看自己的订单）。
攻击请求：/api/order?user_id=456（用户 A 修改user_id为 456，访问用户 B 的订单）。这里通过修改 “对象引用”（user_id）实现的水平越权，就是典型的 IDOR 漏洞。

4 业务场景

4.1 突破限制：业务规则绕过型越权

在 “添加好友返利” 这类场景中，核心业务规则通常包含两层限制：

同一用户只能被添加为好友一次（避免重复返利）。
每个添加行为仅能触发一次返利。

这类越权漏洞的本质，是攻击者通过接口层面的操作，绕过了业务规则中隐含的权限校验逻辑。

风险分析：

假如正常流程中，系统会在添加好友时检查friend_id是否已存在于当前用户的好友列表中，若已存在则返回 “该用户已是好友” 并拒绝重复添加。
但如果接口未严格校验这一关系（仅校验 “当前用户是否登录”，而不校验 “好友关系唯一性”），攻击者可通过重复发送包含相同friend_id的请求，让系统误认为是 “新添加行为”，从而重复触发返利机制。
更深层的风险在于，这类漏洞可能衍生出 “批量越权”：若接口同时未限制 “单次请求添加好友的数量”，攻击者可构造包含多个friend_id的批量请求（如friends=[1001,1001,1001]），甚至结合其他账号的user_id（如遍历user_id=1001到2000），实现跨用户的批量刷取返利，本质上是对 “业务权限边界” 的全面突破。

4.2 VIP 场景：权限标识篡改型越权

VIP 场景的核心是 “权限与付费 / 身份的强绑定”，即特定资源（模板、音视频）或操作（回帖、创建企业账号）仅对 VIP 用户开放。

而标识用户是否具备该权限的关键，往往是请求中的业务类型参数（如template_id=101代表免费模板，template_id=201代表 VIP 专属模板）。

越权漏洞的触发点在于：系统仅通过前端传入的参数值判断权限，而未在后端重新校验 “当前用户是否真的拥有访问该参数对应资源的权限”。

资源访问类：例如某付费视频接口，正常请求为video_id=free_001，VIP 用户可访问video_id=vip_001。若攻击者修改video_id为vip_001，而后端仅校验 “用户是否登录”，未校验 “用户是否购买该 VIP 视频”，则普通用户可直接越权访问付费内容。
操作权限类：例如某论坛回帖功能，普通用户role_id=1仅能在公开板块回帖，VIP 用户role_id=2可在私密板块回帖。若攻击者将请求中的role_id=1改为role_id=2，后端未查询用户实际角色信息进行比对，则普通用户可越权在私密板块发帖，本质是对 “角色权限标识” 的伪造。

这类漏洞的根本原因是 “信任前端参数而忽略后端权限二次校验”，攻击者通过篡改参数中的权限标识，直接绕过了业务层面的付费 / 身份限制，属于典型的 “垂直越权” 场景。

5 WebSocket 越权（少见但风险突出）

WebSocket 作为全双工通信协议，因实时性优势被广泛用于聊天、实时数据推送等场景，但由于其连接建立后持续交互的特性，越权漏洞虽不常见，却可能导致更隐蔽、更持久的权限滥用。

核心原理：连接建立后的权限校验缺失

与 HTTP 每次请求独立校验权限不同，WebSocket 通常在连接握手阶段进行身份认证（如校验 Cookie、Token），但后续的消息交互阶段若未持续校验权限，攻击者可利用已建立的合法连接，发送越权操作指令。

例如：

正常流程：用户 A 登录后，WebSocket 握手时校验 Token 确认身份，后续仅允许发送与 A 相关的操作（如查看自己的聊天记录）。
越权场景：若握手后，系统对消息内容中的操作对象（如target_user_id=B）未校验 “当前用户是否有权操作 B”，攻击者可在 A 的连接中发送{"action":"get_chat","target_user_id":"B"}，直接获取用户 B 的聊天记录。

6 检测方式

6.1 黑盒测试：三步快速定位

识别权限敏感参数
在功能点中寻找与权限相关的参数，例如：
- 用户标识：user_id、uid、username
- 权限标识：role、isAdmin、permission
- 资源标识：order_id、file_id、doc_id
执行越权测试
- 垂直越权：用普通用户账号访问管理员URL（如/admin/dashboard），或修改权限参数（如role=admin）后发送请求。
- 水平越权：用用户A的账号登录，抓取查询个人信息的请求（如/api/user?uid=100），修改uid=101后重放，观察是否返回用户B的信息。
分析响应特征
- 若修改参数后，响应状态码从403 Forbidden变为200 OK，或内容包含敏感数据，可能存在越权漏洞。
- 注意对比"正常请求"与"篡改后请求"的响应差异（如返回内容长度、特定关键词）。

6.2 白盒审计：代码层的漏洞排查

不同语言的权限校验逻辑缺陷具有典型特征，可通过关键词快速定位，这里以 Java SpringBoot 框架为例：

检查 controller 中的接口如@RequestMapping、@GetMapping、@PostMapping、@PutMapping、@DeleteMapping，是否配置了鉴权注解，如未配置注解则检查步骤2，否则接口未进行权限校验；如果配置了权限注解如（@PermissionCheck），则搜索关键字PermissionCheck，检查鉴权逻辑是否存在绕过。
当第1步的接口中没有配置鉴权注解时，检查 Spring 拦截器是否统一进行了权限校验，通过搜索关键字addInterceptors，查看是否存在用于鉴权的拦截器，如果有，检查鉴权逻辑能否被绕过。
检查 Spring Security 配置是否遗漏关键接口的权限控制：

// 危险示例：配置中未限制/admin/**路径的访问权限
http.authorizeRequests()
    .antMatchers("/user/**").permitAll()
    .antMatchers("/admin/**").permitAll(); // 错误：管理员路径允许所有用户访问

7 防御方案

越权漏洞的防御核心是服务器端做足校验，不相信客户端任何数据，具体措施如下：

7.1 严格的权限校验逻辑

垂直校验：对每个接口明确权限等级（如user/manager/admin），每次请求时从服务器会话（如session、token）中获取当前用户角色，判断是否有权访问。
水平校验：访问资源时，不仅验证resource_id的有效性，还要校验"该资源是否属于当前用户"。

7.2 限制参数可控范围

避免在URL或请求体中直接传递敏感权限参数（如isAdmin），改用服务器端存储的角色信息。
对资源 ID 采用随机字符串，避免攻击者通过自增 ID 遍历。
设置流程策略，禁止用户大量猜测资源 ID。

7.3 最小权限原则

给每个用户分配"刚好够用"的权限（如普通用户无删除权限），减少越权后的危害范围。
临时操作（如审批）采用"一次性授权码"，避免长期权限滥用。

7.4 安全的编码规范

前端仅做权限相关的"展示控制"（如隐藏按钮），不做"功能限制"（关键校验必须在后端）。
使用成熟的权限框架（如Spring Security），避免手写校验逻辑出现疏漏。

7.5 日志与监控

记录所有敏感操作的审计日志（包括操作人、擦着时间、客户 IP、操作接口、操作功能、操作结果）
异常访问（如普通用户频繁访问管理员接口）实时告警。

8 总结

越权漏洞作为 Web 应用中最常见、危害最直接的权限类漏洞，其本质是服务器对 “用户身份与操作权限的匹配性” 校验失效。

从纵向越权的低权限用户提权，到横向越权的同级别数据泄露，再到 WebSocket 场景下的持续权限滥用，漏洞形态虽因业务场景不同而有所差异，但核心问题始终围绕 “权限校验逻辑的缺失或松弛”—— 要么依赖前端传递的不可信参数，要么在关键操作环节省略了服务器端的二次校验。

实战中，越权漏洞的检测与防御需紧扣 “业务边界” 与 “技术实现” 两个维度：

对测试人员而言，需重点关注user_id、role、resource_id等敏感参数，通过黑盒测试中的参数篡改与响应对比，或白盒审计中对权限注解、拦截器逻辑的排查，快速定位漏洞点；
对开发人员而言，防御的核心在于服务器端的绝对主导权：所有权限判断必须基于服务器端存储的用户真实信息（如会话、数据库记录），完全摒弃对前端数据的信任，同时通过最小权限原则、审计日志等手段，降低漏洞被利用的风险。