逻辑漏洞红队实战：越权漏洞挖掘思路，水平越权垂直越权各种场景-港品优选

🔒免责声明：本文仅供授权渗透测试、红蓝对抗、SRC 安全研究学习，所有实验操作请在自建靶场完成。未经授权对互联网业务进行越权测试属于违法行为，请严格遵守网络安全法律法规。

前言

越权漏洞（Broken Access Control，BAC，也叫 IDOR 不安全的直接对象引用），常年位居 OWASP Top10 高危漏洞榜单，在 SRC 挖洞、护网红队实战中产出占比极高。与 SQL 注入、XSS 这类代码层漏洞不同，越权属于典型业务逻辑漏洞，扫描器很难百分百识别，极度依赖人工业务分析。很多开发只做前端按钮隐藏、页面跳转控制，完全缺少后端接口鉴权校验，导致普通用户可以读取其他用户隐私数据、调用管理员接口、篡改他人业务数据。

越权分为两大核心类别：水平越权（同级横向越权）、垂直越权（高低权限纵向提权），除此之外还存在未授权访问、向下越权、跨租户越权、批量赋值越权等衍生场景。很多新手挖洞只会简单修改 URL 里面的 id 参数，遇到参数加密、token 鉴权、restful 接口、JSON 请求就无从下手。本文万字完整复盘红队实战挖掘思路，覆盖原理、多类真实业务场景、各类绕过手段、测试流程、踩坑误报分析、代码审计、完整修复方案。适合 Web 渗透、SRC 白帽子、后端开发安全学习。

ATT&CK 映射：T1068 利用权限不足，T1555 凭证获取，T1210 权限提升横向移动。

一、越权漏洞基础理论

1.1 什么是水平越权

水平越权（Horizontal Privilege Escalation）：同一权限等级的用户之间互相访问对方私有资源。
A 用户和 B 用户角色完全一样，都是普通会员。A 本只能查看自己的订单、手机号、收货地址、账单，因为后端缺少数据归属校验，修改请求中的资源 ID，直接读取或者修改 B 用户的数据。

通俗例子：

用户 A 修改订单 id，查看用户 B 全部订单、手机号、收货地址；
修改用户 id，查看别人的工资、病历、聊天记录；
修改文档 id，打开其他用户私有文档。

关键点：角色不变，访问别人同等级的私有数据。

1.2 什么是垂直越权

垂直越权（Vertical Privilege Escalation）：低权限用户访问高权限角色功能，也叫权限提升。
普通用户账号，直接调用管理员接口，执行管理员操作，比如新增账号、删除用户、修改全站配置。分为向上越权（低→高，最常见高危）、向下越权（管理员操作普通用户，一般不算漏洞）。

通俗例子：

普通用户直接访问/admin/userList管理员用户列表接口；
请求修改角色字段，把自己账号 role 改为 admin；
普通用户调用接口审批订单、修改系统参数。

关键点：角色发生改变，获得更高等级操作能力。

1.3 漏洞产生根本原因

越权漏洞本质只有一句话：认证和鉴权分离，只做登录身份认证，不做资源访问鉴权腾讯云。

完整安全流程两步：

身份认证（Authentication）：确认你是谁，登录拿到 session/token，判断你是否登录；
权限鉴权（Authorization）：确认你能干什么，判断当前登录账号，是否有权访问这条数据、调用这个接口。

大量业务只完成第一步，只要登录成功就放行所有请求，没有第二步校验。

高危开发错误行为：

信任客户端传来的user_id、order_id、doc_id，直接拼接数据库查询，没有校验这条记录属于当前登录用户；
权限只在前端做控制，前端隐藏按钮，后端接口没有校验；
从 http 参数、body 拿用户 id，不从 token/session 服务端解析读取用户身份；
统一鉴权拦截器漏掉部分新接口；
不同接口两套鉴权逻辑，部分接口鉴权失效；
多租户系统，没有租户隔离，A 租户读取 B 租户全部业务数据；
批量赋值漏洞，允许客户端直接修改 role、is_admin 权限字段。

1.4 越权漏洞风险等级

漏洞类型	风险等级	典型危害
水平越权读取大量用户隐私数据	高危	批量泄露手机号、身份证、订单信息
水平越权修改 / 删除他人数据	高危	篡改别人订单、删除别人文档
垂直越权普通用户获取管理员权限	严重高危	接管后台，新增删除账号，控制整个系统
跨租户越权	严重高危	读取其他企业租户全部业务数据
越权仅读取单条无关公开信息	低危	无实际业务危害，一般不提交漏洞

注意：同样是水平越权，只读和可写危害差距巨大；能批量遍历自增 ID，危害成倍放大。

二、水平越权各类真实业务实战场景

水平越权是 SRC 出现频率最高的漏洞，几乎覆盖所有业务系统：电商、OA、CRM、社交、网盘、工单系统、人事系统。

2.1 GET 请求 URL 参数越权（最经典场景）

业务接口示例：

GET /api/getOrderInfo?order_id=10086 HTTP/1.1 Cookie: session=xxxxxxx

登录账号 A，A 的订单 id=10086；把 order_id 修改为 B 用户订单 id=10087，服务器直接返回 B 完整订单信息，手机号、收货地址。

测试要点：id 参数不一定叫 id，常见参数名：order_id、uid、user_id、doc_id、msg_id、bill_id、record_id、article_id。

坑点：部分接口 id 不是数字，是 UUID 字符串，无法简单枚举，但是如果前端页面泄露其他用户 id，依然可以越权。

2.2 POST 表单 / JSON 请求体越权（高频容易被忽略）

很多新手只会测试 URL 参数，忽略 POST 请求 body 里面可控 id。

JSON 数据包示例：

POST /api/user/getUserDetail HTTP/1.1 Content‑Type: application/json Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... { "user_id":1001 }

当前登录用户是 1001，修改"user_id":1002，服务端直接返回 1002 用户个人信息。

核心开发错误：后端直接读取请求 body 中的 user_id，没有从 JWT token/session 解析当前登录用户 id 做归属校验。不管 token 是谁，只要客户端传 user_id 就查对应数据。

2.3 Restful 路径参数越权

现在前后端分离大量 Restful 风格接口，id 放在 url 路径里面：

GET /api/order/10086 GET /api/document/521

Burp 修改路径中的数字，替换其他资源编号测试越权。

2.4 可写型水平越权（比读取危害更大）

不止读取数据，如果修改、删除操作存在水平越权，危害会大幅上升。
场景 1：修改他人收货地址

POST /api/order/updateAddress {"order_id":2001,"address":"攻击者地址"}

登录自己账号，修改 order_id 为别人订单，直接篡改别人订单收货地址。

场景 2：越权删除别人文档、工单、留言。

这类漏洞属于高危，SRC 评分很高，不仅仅是信息泄露，可以造成业务破坏。

2.5 批量遍历水平越权

资源 ID 是自增数字，越权接口没有做频率限制，写脚本循环遍历 id，批量拉取全站用户订单、个人信息，造成大规模数据泄露。
实战现象：改 id=1 返回数据，id=2 返回数据，一直遍历成千上万条用户私有数据。

2.6 参数加密场景的水平越权（实战难点）

很多系统把 id 做 AES/RSA 加密，URL 传递加密后的字符串，直接修改数字会解密失败，很多人到此放弃测试。

红队实战测试思路：

抓包 A 用户加密 id，抓包 B 用户加密 id；直接复制 B 的加密参数替换到 A 的请求发包；
JS 逆向，找到前端加密函数，使用 Burp 插件或者 Python 脚本生成其他 id 加密参数；
寻找同类其他接口，是否存在未加密的同功能接口；
观察是否存在解密之后没有校验数据归属，只校验加密签名有效性。

坑：部分接口只校验参数加密签名是否合法，签名正确就放行，不校验这条数据属于哪个登录用户，依然产生越权。签名只能防篡改，不能解决访问控制问题。

2.7 多条件联合参数越权

接口需要同时传递多个参数才可以查询，单一修改一个参数无法触发。
示例：

GET /api/getRecord?user_id=1001&record_id=3001

后端 SQL 伪代码：

select * from record where user_id = $_GET['user_id'] and id = $_GET['record_id']

开发以为传入自己 user_id 就安全，但是 user_id 完全可控，攻击者把 user_id 改为别人 id，record_id 对应别人记录，直接查询成功。

根因：直接信任客户端全部传入条件，不从 session 固定填充当前登录用户 id。

三、垂直越权各类业务实战场景

垂直越权实现低权限提升至高权限，一旦复现成功属于高危严重漏洞，红队护网中价值极高。垂直越权难度普遍高于水平越权，需要梳理系统角色权限模型。

常见角色划分：普通用户、VIP 用户、运营、管理员、超级管理员。

3.1 直接访问管理员接口路径（未做角色拦截）

业务后端拦截器只校验是否登录，不校验角色身份。普通用户登录之后，直接访问管理员接口地址。

示例接口：

GET /admin/user/list 查询全部用户列表 POST /admin/user/delete 删除账号 POST /admin/config/save 修改系统配置

普通用户 token 带上请求，直接返回管理员数据，执行管理员操作。

坑：前端页面看不到管理员菜单，只是前端隐藏，后端接口没有权限拦截。很多开发误以为前端看不到别人就访问不到。

3.2 请求体可控 role 角色字段，批量赋值垂直越权

业务更新用户信息接口：

POST /api/user/updateInfo { "user_id":1001, "username":"test", "role":"admin" }

普通用户调用更新自己资料接口，修改请求里面role:user改成role:admin，后端直接把数据库中自己账号角色更新为管理员，实现垂直权限提升。

漏洞根源：后端使用对象直接接收全部前端参数，没有做字段白名单过滤，允许客户端直接修改权限角色字段，这就是经典批量赋值（Mass Assignment）漏洞GitHub。

3.3 越权调用管理员业务功能接口

不需要访问 /admin 路径，业务接口本身具备管理员操作能力，缺少角色校验。
场景举例：

普通用户调用订单审批接口，审批别人订单；
普通用户调用接口，生成系统优惠券；
普通用户调用接口重置其他用户密码。

3.4 Cookie、请求头携带可控角色参数

业务从请求头、Cookie 读取用户角色，而非从服务端 session/token 解析。

Cookie: role=user;userid=1001

攻击者修改 Cookie 里面role=admin，后端直接采信，获得管理员权限。

3.5 JWT payload 可控 role 字段垂直越权

注意区分两种完全不同情况：

JWT 签名校验失效（none 算法、密钥泄露）：可以直接修改 payload 的 role 为 admin，生成伪造 token，实现垂直越权；
签名校验正常通过，但是业务直接信任 payload 中 role 字段，允许普通用户正常 token 下修改请求参数传入 role=admin，这不属于 JWT 漏洞，属于业务越权漏洞。

非常重要的误报点：JWT 签名完好，仅仅修改 HTTP 请求 body 里面 role 参数，不是修改 JWT 内部 payload。

3.6 越权向下越权（管理员操作普通用户，一般不算漏洞）

管理员账号操作普通用户数据，属于业务设计功能，不属于漏洞；但是如果普通用户可以冒充管理员执行向下操作，就是高危垂直越权。

四、衍生越权漏洞场景，实战经常遇到

4.1 未授权访问（越权特殊形态）

没有登录 session/token，直接访问接口获取数据。没有身份认证环节。

不需要 Cookie、Authorization 头，直接 GET 请求拿到用户数据；
管理后台不需要登录直接访问。

区分：未授权访问 = 没有登录也能访问；越权 = 已经登录，但是访问不属于自己权限的数据。

4.2 跨租户越权（SaaS 系统高危）

SaaS 多租户平台，每个企业是独立租户，租户之间数据物理或者逻辑隔离。
A 租户登录账号，修改租户 id 参数，读取 B 租户全部业务数据。
伪代码 SQL：

select * from business_data where tenant_id = $_POST["tenant_id"]

没有从 session 固定读取当前登录租户 id，完全接收客户端传入 tenant_id，造成跨租户数据泄露，属于严重高危漏洞。

4.3 业务流程类越权

业务流程场景，鉴权逻辑写在流程前端步骤，后续接口不再校验。
场景 1：订单支付流程，校验一次身份之后，后续修改金额、修改收货地址接口不再鉴权；
场景 2：工单系统，创建工单校验身份，修改、删除工单不再校验归属；
场景 3：重置密码流程，校验手机号之后，后续接口没有校验该手机号归属当前账号，越权重置他人密码。

4.4 部分接口鉴权遗漏（拦截器漏接口）

Spring、Shiro 拦截器配置，新增接口忘记配置权限规则，老接口鉴权，新接口完全放行。
典型现象：系统大部分接口防护正常，某几个新增接口存在越权，其他接口无问题。代码审计重点看拦截器配置文件。

五、越权漏洞标准化红队挖掘测试流程

挖越权不要盲目改 id，遵循标准化流程，提升产出，减少误报。

5.0 前期准备：准备两套账号

账号 A：普通账号 A；账号 B：普通账号 B（同角色）；账号 Admin：管理员账号。

水平越权测试：A 账号会话，访问 B 账号资源；
垂直越权测试：普通 A 账号会话，调用管理员功能接口。

两套账号是测试越权最基础条件，很多新手只使用一个账号，根本无法判断是否越权。

5.1 梳理全部业务接口

完整走一遍业务功能，Burp 抓包，收集所有接口 URL、HTTP 方法、请求参数；
重点关注：查询个人信息、订单、账单、文档、修改资料、删除、审批、用户管理；
标记接口中所有可控参数：id、order_id、user_id、doc_id、tenant_id、role 等；
区分：GET 查询、POST 新增、POST 修改、DELETE 删除接口。

5.2 水平越权测试步骤

使用账号 A 登录，拿到 A 的 session/token；
操作业务，抓包获取 A 自己资源 ID（order_id=1001）；
切换账号 B，获取 B 对应的资源 ID（order_id=1002）；
保持 A 账号的 Cookie/token 不变，把请求中资源 id 修改为 B 的 id，发送数据包；
判断返回结果：
- 返回 B 用户私有数据，或者成功修改 B 数据 → 水平越权漏洞存在；
- 返回 401/403，提示无权限，返回空数据 → 防护正常；
- 返回 A 自己数据，后端强制覆盖参数 → 防护正常。

重点：会话凭证不能换！必须使用 A 的 token 去访问 B 的数据。很多人测试时顺带替换 Cookie，造成测试失效。

5.3 垂直越权测试步骤

普通账号登录，拿到普通账号 token；
收集管理员账号使用过的接口路径；
使用普通账号 token，直接请求管理员接口；
测试修改请求体中 role、权限相关参数；
观察是否返回管理员数据、执行管理员操作。

5.4 特殊场景测试清单

参数加密场景：复制其他用户加密 id 参数替换测试；逆向生成加密参数；
Restful 接口修改路径里面 id；
JSON 请求重点测试 body 内部 id、role；
测试多参数联合查询；
SaaS 系统专门测试 tenant_id 租户参数；
测试删除、修改类写接口，不止测试查询读接口。

5.5 漏洞验证必须形成完整证据链

提交 SRC 漏洞报告必须要有完整证据链，缺一不可：

请求携带低权限账号会话凭证；
请求目标资源明确归属另外一个用户；
接口返回对方私有数据，或者对方业务状态真实发生变化；
完整截图：请求包、响应包，两套账号信息。

只修改 id 返回 200，但是返回的还是自己的数据，不属于漏洞。

六、实战高频踩坑、大量误报场景（SRC 挖洞必看）

越权漏洞是误报重灾区，很多新手提交大量无效报告，需要分清真实漏洞和正常业务逻辑。

坑 1：修改 id 返回 200，但是返回数据仍然是自己账号数据

后端服务端直接覆盖客户端传入 user_id，强制从 session 读取登录用户 id，不管你传什么参数，查询永远是自己数据。这属于防护生效，不是漏洞。

坑 2：更换 Cookie 进行测试

测试水平越权，把 A 的 id 同时把 Cookie 换成 B 的 Cookie，返回 B 数据，这是正常登录逻辑，完全不是漏洞。会话凭证必须保持不变。

坑 3：返回公开通用数据，不属于越权

修改 id 返回公开文章、公开公告，所有用户本来就允许访问，没有私有敏感信息，不算漏洞。越权漏洞访问的必须是私有、仅归属特定用户的数据。

坑 4：JWT payload 的 role 和 http body 里面 role 区分开

修改 JWT 令牌内部 payload 的 role 并且签名绕过成功：真实垂直越权；
JWT 令牌完全不变，仅仅修改 http 请求 body 里面 role 字段，后端没有更新数据库角色，只是响应包显示 role=admin，数据库账号角色没有改变：误报。要看数据库真实变化，不要只看响应返回。

坑 5：前端校验，后端实际拦截

前端页面按钮不能点击，但是 Burp 发包请求直接返回 403，后端已经鉴权，前端只是 UI 表现，防护正常，不是漏洞。

坑 6：管理员账号访问普通用户资源

管理员本来业务设计就允许查看全部用户，这是业务功能，不属于越权漏洞。

坑 7：id 为 UUID，无法枚举，但是可以拿到别人 id 才能触发

没有办法爆破 UUID，但是前端页面泄露其他用户 UUID，复制 UUID 测试，如果成功越权依然是有效漏洞；不能枚举不等于不存在漏洞。

坑 8：部分接口返回数据脱敏

接口返回别人数据，手机号做掩码 138****1234，如果原始完整明文返回才是高危；全部字段脱敏无敏感信息，危害大幅降低。

坑 9：多接口两套鉴权逻辑

查询接口鉴权失效存在越权，修改接口鉴权正常。这个时候查询越权依然是真实漏洞，分开评估危害。

七、代码审计越权漏洞危险特征与安全代码示例

7.1 危险伪代码（存在越权漏洞）

危险示例 1：直接读取 GET 参数查询，不校验归属

//漏洞代码，直接接收客户端order_id $order_id = $_GET['order_id']; $sql = "select * from `order` where id = ".$order_id; $query = mysqli_query($conn,$sql); //直接返回订单数据，没有判断订单属于当前登录用户

危险示例 2：从 http body 拿 user_id，不从 session 获取

//危险Java Spring代码 @PostMapping("/getUser") public Result getUser(@RequestBody UserDTO dto){ //直接读取前端传过来userId，没有和登录用户对比 User user = userMapper.selectById(dto.getUserId()); return Result.success(user); }

危险示例 3：批量赋值，接收 role 字段

//漏洞：直接把前端参数全部set到数据库对象 @PostMapping("/update") public Result update(@RequestBody User user){ userMapper.updateById(user); return Result.success(); } //前端传入{"id":1001,"role":"admin"}，直接修改角色

危险示例 4：管理员接口只校验登录，不校验角色

//只判断是否登录，没有判断角色是不是admin if(session.getAttribute("userId")!=null){ //执行管理员删除操作 userMapper.deleteById(id); }

7.2 安全修复代码示例

修复水平越权查询：服务端从 session 拿当前登录 id，做归属校验

@GetMapping("/getOrder") public Result getOrder(Long orderId, HttpSession session){ //服务端会话获取当前登录用户ID，绝对不从前端拿 Long loginUserId = (Long)session.getAttribute("loginUserId"); //查询同时校验订单归属当前登录用户 Order order = orderMapper.selectOne( Wrappers.lambdaQuery(Order.class) .eq(Order::getId,orderId) .eq(Order::getUserId,loginUserId) ); if(order == null){ return Result.fail("无权限访问"); } return Result.success(order); }

核心思想：查询条件的登录用户 ID，服务端内部生成，永远不信任客户端传来的值。

修复批量赋值漏洞，参数接收使用 DTO 白名单，禁止直接接收完整数据库实体对象

//DTO只接收允许修改字段，role字段不在DTO里面，前端无法传入 public class UserUpdateDTO{ private Long id; private String username; private String phone; //去掉role,is_admin字段，不接收 }

修复垂直越权：接口增加角色校验

//校验用户角色必须为管理员 if(!"admin".equals(session.getAttribute("userRole"))){ return Result.fail("权限不足"); }

7.3 鉴权框架配置错误点

Spring Security、Shiro 经常出现配置错误：

接口只配置 isAuthenticated () 只要登录就放行，没有 hasRole 校验；
路径匹配规则写错，/admin/*只匹配一级路径，/admin/user/list不会拦截，应该配置/admin/**；
新开发接口忘记加到权限拦截规则中。

八、生产环境完整加固修复方案

越权漏洞不能依靠单一手段，多层防护。

8.1 核心原则：鉴权逻辑必须写在服务端

禁止依靠前端隐藏按钮、前端 JS 做权限控制，所有接口后端必须做鉴权校验，前端只是 UI 展示，不能作为安全边界。
身份认证和资源鉴权分开：登录判断你是谁；每个接口必须再判断你能不能操作这条数据。
当前登录用户 ID、租户 ID，服务端从 session/JWT token 解析获取，永远不要从 http 请求参数、body 获取身份标识。客户端传上来的用户 id 只当做业务参数，必须二次比对归属关系。

8.2 水平越权防护要点

查询数据库 SQL 强制增加归属条件：user_id = 当前登录账号id；
对外尽量不暴露自增数字 ID，业务对外使用随机 UUID，降低批量遍历风险；
对查询类接口增加访问频率限制，防止脚本批量遍历 ID 拉取数据；
写操作（修改删除）除归属校验，增加业务操作日志记录。

8.3 垂直越权防护要点

管理员接口增加角色白名单校验，普通用户禁止访问管理接口；
严格禁止批量赋值漏洞，接收参数使用 DTO 白名单，过滤 role、is_admin 等权限字段；
统一拦截器对所有接口生效，上线前核对所有新增接口权限配置。

8.4 SaaS 多租户系统防护

每条 SQL 强制拼接租户 id，租户 id 由服务端会话解析，拒绝客户端传入 tenant_id 参数。

8.5 参数加密与签名的正确定位

参数加密、请求签名只能防参数篡改，不能代替权限鉴权校验。就算签名完全合法，后端仍然要校验资源归属登录用户。很多开发误以为加了签名就不会越权，这是巨大误区。

8.6 安全测试流程

版本迭代新增接口，必须做越权测试；
使用两套账号做测试，模拟水平、垂直场景；
代码审计重点检查：是否从客户端获取用户身份标识，是否每条接口做归属校验。

九、越权漏洞 SRC 报告编写模板参考

漏洞标题：XX 系统水平越权漏洞，可越权查询其他用户订单信息
漏洞描述：系统 /api/getOrderInfo 接口，登录普通账号之后，修改 order_id 参数，可以读取其他用户订单、手机号、收货地址等敏感信息，造成用户隐私泄露。
复现步骤：
使用账号 A（普通账号，账号 A 订单 id=10001）登录系统，抓包请求 /api/getOrderInfo?order_id=10001；
保持账号 A 的 Cookie 不变，修改 order_id 为账号 B 的订单 id=10002，发送请求；
接口返回账号 B 的完整订单数据，包含手机号、收货地址。
漏洞证明：附上请求包截图、响应包截图，两套账号信息截图，敏感信息做脱敏打码。
危害：攻击者可遍历 order_id 批量获取大量用户订单与个人隐私数据，造成大规模信息泄露。
修复建议：后端接口查询订单时增加归属校验，校验该订单记录属于当前登录会话的用户，拒绝访问不属于自己的订单数据，登录用户 id 从 session 服务端解析，不要信任客户端传入参数。

注意：提交报告敏感数据必须脱敏打码，保护用户隐私。

总结

越权漏洞是红队实战、SRC 挖洞产出最高的逻辑漏洞，漏洞根源不是复杂的代码漏洞，而是开发权限逻辑设计缺失，只做登录认证，缺少接口资源鉴权校验。

水平越权：同角色账号，访问别人私有数据；测试关键点：会话不变，修改资源 ID 访问其他用户数据。
垂直越权：低权限调用高管理员接口，实现权限提升；重点测试管理员接口、角色字段参数。
衍生场景包含未授权访问、跨租户越权、批量赋值越权；Restful 接口、JSON 请求、参数加密场景同样存在越权。
测试越权必须准备两套账号，保持会话凭证不变，构建完整证据链，区分大量误报场景。
修复核心准则：鉴权全部放在服务端；登录用户 id 从 session/token 解析，永远不要信任客户端传来的身份标识；查询强制校验数据归属关系；使用 DTO 白名单防止批量赋值漏洞。

扫描器对越权识别能力有限，大部分漏洞依赖人工业务梳理。在护网实战中，很多业务 WAF 可以拦截注入类漏洞，但是逻辑越权漏洞 WAF 很难识别，经常成为红队突破业务系统的重要突破口。