2026-07-03 05:02:22 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文详解越权访问漏洞在金融行业业务系统中的表现、成因与防御方案。核心观点是越权漏洞本质在于服务端未校验操作者对操作对象的访问权限，分为水平越权、垂直越权和未授权访问三类。文章通过银行存单比喻帮助理解，并逐一拆解了账户查询、交易记录、信贷审批等六大高发业务场景中的漏洞表现与攻击链路。最后提供了按业务模块分类的高发功能点清单，强调越权漏洞是银行系统中最常见且最易被忽视的高危风险。 综合评分： 85 文章分类： WEB安全,渗透测试,红队,内网渗透,安全意识

cover_image

金融行业信息安全培训课程（三）: 越权访问漏洞详解-文末考试

原创

H H

401 Unauthorized

2026年7月1日 18:10 安徽

在小说阅读器读本章

去阅读

写在前面

如果说注入漏洞是”从数据库偷数据”，认证漏洞是”偷钥匙进屋”，那么越权漏洞就是——你已经拿到钥匙进了屋，但你本应该只能进客厅，结果发现卧室、书房、甚至楼上邻居家的门你都能打开。在银行业务系统中，越权漏洞是最常见、最高发、却最容易被忽视的漏洞类型。它不需要高超的技术手段，往往只需要修改一个 URL 参数、一个请求里的用户 ID，就能看到别人的账户、别人的交易、别人的贷款审批信息。本文将从一张银行存单的比喻入手，带你理解越权的本质，再逐一拆解银行业务中每一类越权漏洞的成因、场景和防御方案。

一、越权访问漏洞到底是什么？

1.1 一个比喻帮你彻底理解越权

你去银行柜台，想查一下自己的账户余额。柜员问了你的名字，然后就去后台查了。但你突然说：”诶，顺便帮我也看看隔壁老王的账户余额呗？”——如果柜员不核实你和老王的关系，直接就把老王的账户信息给你了，这就是越权。

在技术世界里，”柜员”就是后端服务器，”账户编号”就是请求里的参数。如果服务器收到”查询账户编号=138″的请求时，不验证”当前用户是否有权访问账户138″，仅凭账户编号就返回数据，任何人都可以随意修改这个编号来查看他人的信息。

越权漏洞的核心本质：服务端没有校验”当前操作者”对”当前操作对象”的访问权限。

1.2 越权漏洞与其他漏洞的区别

1.3 越权漏洞的三大类型

二、水平越权（平行越权）详解

2.1 什么是水平越权

同一角色、同一权限等级的 A 和 B 两个用户，A 能访问 B 的私有数据——这就是水平越权。

场景化理解：

你和同事都住同一栋公寓楼，每人有自己的房间钥匙。你的钥匙本应该只能开你的门。但如果你发现你的钥匙居然能打开同事的房门——这就是水平越权。在银行系统里，”钥匙”就是你登录后的身份凭证，”房门”就是别人的账户数据。

2.2 水平越权的技术根源

银行系统中最典型的越权代码模式：

❌ 危险的写法：

-- 前端请求：GET /api/account/detail?accountId=138 -- 后端直接执行： SELECT * FROM accounts WHERE account_id = 138 -- ❌ 没有任何用户归属校验！任何人改 accountId 就能查任何账户

✅ 安全的写法：

-- 前端请求：GET /api/account/detail?accountId=138 -- 后端先验证归属，再查询： SELECT * FROM accounts &nbsp;WHERE account_id = 138 &nbsp; &nbsp;AND user_id = CURRENT_USER_ID() &nbsp;-- ✅ 加上了归属条件

核心问题就一句话：查询条件里有没有加上”当前用户”的限制？

2.3 银行业务中水平越权的六大高发场景

2.4 水平越权攻击链路演示

以查看他人账户余额为例，一个完整的攻击链路：

| 步骤 | 操作 | 正常用户 | 攻击者 | | — | — | — | — | | ① | 登录手机银行 | 张三登录，查看自己的账户 | 李四登录，正常操作 | | ② | 进入”我的账户” | 前端请求 /api/accounts?userId=10001 | 抓包拦截请求 | | ③ | 篡改参数 | — | 将 userId=10001 改为 userId=10002 | | ④ | 重放请求 | — | 发送修改后的请求 | | ⑤ | 获取数据 | 正常看到自己的账户 | ✅ 看到了 userId=10002（张三）的账户余额和卡号 |

攻击者只需要写一个简单的脚本，从 10001 遍历到 99999，就能批量获取所有用户的账户信息。一个接口 + 一个循环 = 一次数据泄露事故。

三、垂直越权（权限提升）详解

3.1 什么是垂直越权

低权限用户（如普通用户、普通柜员）能够执行高权限用户（如管理员、审批人）才能执行的操作。本质是权限校验缺失或可绕过。

场景化理解：

公司办公楼有门禁系统。普通员工的门禁卡只能开 1-3 楼的办公室，高管的卡能开所有楼层包括机房。但如果一个普通员工发现，只要把电梯按钮”用力按两下”就能直接到机房——这就是垂直越权。门禁系统看起来有，但存在绕过方式。

3.2 银行业务中垂直越权的五种典型表现

3.3 垂直越权攻击链路演示

以普通用户绕过审批直接放款为例：

四、未授权访问详解

4.1 什么是未授权访问

不需要任何身份凭证（不需要登录），直接通过 URL 就能访问本应受保护的页面或接口。这是越权的最极端形式——权限校验被完全跳过。

场景化理解：

银行后台管理系统通常需要用户名+密码+U盾才能登录。但如果有人发现，在浏览器直接输入 https://bank.com/admin/dashboard 就能直接进入后台——不需要登录——这就是未授权访问。

4.2 银行业务中未授权访问的高发位置

4.3 一个典型的未授权访问攻击链路

| 步骤 | 操作 | 说明 | | — | — | — | | ① | 攻击者对银行系统进行子域名扫描 | 发现 admin.bank.com、monitor.bank.com 等 | | ② | 直接访问 admin.bank.com/login | 被拦截，需要登录 | | ③ | 尝试访问 admin.bank.com/swagger-ui.html | ✅ 直接打开！查看所有 API 接口 | | ④ | 从 Swagger 中找到 /api/admin/user/resetPassword | 接口参数：userId, newPassword | | ⑤ | 直接调用该接口 | ✅ 成功重置管理员密码 | | ⑥ | 用新密码登录后台 | 获取全量客户数据、交易记录 |

五、越权漏洞在银行业务系统中的高发功能点

本节将所有越权漏洞类型与银行真实业务模块做一一对应，帮助业务人员快速定位自己负责的系统是否存在风险。

5.1 按业务模块分类

用户认证与账户管理模块

支付转账与资金清算模块

信贷审批与账务核算模块

积分权益与营销活动模块

内部管理与后台运维模块

第三方合作与开放接口模块

5.2 按请求参数特征快速识别越权风险

| 参数类型 | 越权风险 | 说明 | | — | — | — | | 用户标识userId``user_id``uid | 🔴 极高 | 最常见的越权入口，修改后可访问他人数据 | | 业务对象 IDorderId``accountId``cardId``loanId | 🔴 极高 | 任何自增或有规律的 ID 都可能被遍历 | | 手机号/身份证phone``mobile``idCard | 🔴 高 | 作为查询条件时如果没有归属校验，可遍历 | | 页码/偏移量page``offset``start | 🟡 中 | 如果列表不做归属过滤，分页查询也能批量获取数据 | | 文件路径filePath``path``url | 🔴 高 | 可能被利用做目录遍历或未授权下载 | | 角色/权限标记role``isAdmin``permission | 🔴 极高 | 如果这些参数由前端传入且后端采信，可直接提权 |

六、如何判断业务系统是否存在越权漏洞

6.1 黑盒测试方法

水平越权测试

垂直越权测试

未授权访问测试

6.2 白盒代码审计方法

六步代码审计法

| 步骤 | 审计内容 | 检查要点 | | — | — | — | | ① 找入口 | 找到所有 Controller/Handler，列出所有对外暴露的接口 | 检查每个接口的 URL、参数列表 | | ② 看参数 | 审查每个接口的请求参数，重点关注用户 ID、业务对象 ID | 记录所有可被篡改的 ID 类参数 | | ③ 追鉴权 | 跟踪每个接口的鉴权逻辑——是否有 @PreAuthorize、拦截器、Filter | 是否有接口遗漏了鉴权注解 | | ④ 核归属 | 检查数据查询/操作时，是否将”当前用户”作为过滤条件 | 查询语句中是否包含 userId = currentUser.id | | ⑤ 验角色 | 检查操作类接口（增删改）是否校验了用户角色权限 | 是否有接口未区分普通用户和管理员 | | ⑥ 查配置 | 检查 Spring Security / Shiro 的拦截器配置，是否有遗漏的路径 | 配置中是否有 /admin/** 被遗漏 |

代码审计检查清单

| 编号 | 检查项 | 是否通过 | | — | — | — | | C1 | 所有数据查询是否带上了当前用户 ID 的条件过滤？ | ☐ | | C2 | 是否有查询直接使用请求参数中的 ID 而不校验归属？ | ☐ | | C3 | 所有管理类接口是否有角色权限校验（非仅登录校验）？ | ☐ | | C4 | 增删改操作接口是否校验了操作权限和数据归属？ | ☐ | | C5 | 是否有接口通过前端传入的 role/permission 参数判断权限？ | ☐ | | C6 | 权限拦截器配置是否覆盖了所有接口路径？是否有遗漏？ | ☐ | | C7 | 生产环境是否关闭了 Swagger、Actuator 等调试/监控端点？ | ☐ | | C8 | 是否存在可通过 URL 猜测直接访问的静态资源（备份文件、日志等）？ | ☐ | | C9 | 文件下载接口是否校验了文件归属和路径合法性？ | ☐ | | C10 | 批量导出/查询接口是否有数据范围限制？ | ☐ |

6.3 越权漏洞的典型 HTTP 响应特征

| 情况 | HTTP 响应 | 说明 | | — | — | — | | 正确的安全实现 | 403 + {"code": 403, "message": "无权限"} | 明确拒绝 | | 隐蔽的安全实现 | 200 + {"data": null} 或 200 + 空列表 | 不暴露信息差异，但本质上已阻止 | | 明显的漏洞 | 200 + 返回了他人的完整数据 | 典型越权 | | 数据脱敏但仍有信息泄露 | 200 + 返回了部分数据（姓名脱敏但金额可见） | 仍是越权，只是做了表面处理 | | 返回错误但暴露了信息 | "userId=10002 不存在" vs "账户余额为 0 元" | 虽然不是越权，但暴露了用户是否存在 |

七、越权漏洞的防御方法

7.1 核心防御原则：三层校验模型

三层缺一不可。每一层都必须独立校验，不能依赖上一层已经校验过就跳过。

7.2 水平越权防御方案

方案一：查询条件强制绑定当前用户（推荐）

✅ 正确模式： // 用户查询自己的账户 @GetMapping(“/api/account/{accountId}”) public Account getAccount(@PathVariable Long accountId) { // 从 Token/Session 中获取当前登录用户 Long currentUserId = SecurityContext.getCurrentUserId(); // 查询时必须带上当前用户 ID 作为条件 return accountService.findByAccountIdAndUserId(accountId, currentUserId); // ✅ 即使前端传了他人的 accountId，由于不匹配 currentUserId， // 查询不到任何数据，自然无法越权 }

方案二：统一数据权限过滤器（高级）

使用 AOP 切面或 MyBatis 拦截器，自动为所有查询追加归属条件：

| 方式 | 实现 | 优点 | 缺点 | | — | — | — | — | | ORM 拦截器 | MyBatis Interceptor 自动追加 WHERE user_id = #{currentUserId} | 统一、不易遗漏 | 需要处理特殊场景的豁免 | | AOP 切面 | 在 Service 层切面校验入参 ID 是否属于当前用户 | 灵活、可精细控制 | 需要为每个 Service 方法配置 | | 数据权限框架 | 使用 Spring Security ACL / Apache Shiro 的数据权限模块 | 成熟、文档齐全 | 引入较重，学习成本高 |

7.3 垂直越权防御方案

方案一：基于角色的接口权限控制（RBAC）

✅ 正确的权限模型： &nbsp;@RestController @RequestMapping("/api/admin") public class AdminController { &nbsp; &nbsp; &nbsp;// 只有 ADMIN 角色可以调用 &nbsp; &nbsp; @PreAuthorize("hasRole('ADMIN')") &nbsp; &nbsp; @PostMapping("/approveLoan") &nbsp; &nbsp; public Result approveLoan(@RequestBody ApprovalRequest req) { &nbsp; &nbsp; &nbsp; &nbsp; // ... &nbsp; &nbsp; } &nbsp; &nbsp; &nbsp;// 只有 ADMIN 或 APPROVER 角色可以查看 &nbsp; &nbsp; @PreAuthorize("hasAnyRole('ADMIN', 'APPROVER')") &nbsp; &nbsp; @GetMapping("/applications") &nbsp; &nbsp; public List<Application> listApplications() { &nbsp; &nbsp; &nbsp; &nbsp; // ... &nbsp; &nbsp; } }

关键要求： 权限判断必须在服务端完成。前端隐藏菜单只是 UI 层的便利，不能作为安全控制手段。

方案二：权限判断规则

7.4 未授权访问防御方案

| 措施 | 具体做法 | 优先级 | | — | — | — | | 全局登录拦截器 | 配置 Filter/Interceptor，对所有需要认证的路径进行拦截，未登录统一返回 401 | 🔴 最高 | | 生产环境关闭调试端点 | 关闭 Swagger UI、Spring Boot Actuator、Druid 监控等 | 🔴 最高 | | 敏感路径白名单机制 | 只允许特定 IP 访问后台管理页面（或通过 VPN） | 🟡 高 | | 静态资源权限控制 | 将可下载的文件（报表、备份）放在非 Web 可访问目录，通过接口鉴权后下载 | 🟡 高 | | 定期路径扫描 | 定期使用目录扫描工具检查是否有遗漏的未授权接口 | 🟢 中 |

7.5 防御架构总览图

八、银行业务人员自查清单

8.1 开发人员自查清单

| 编号 | 自查项 | 是否完成 | | — | — | — | | D1 | 我开发的所有查询接口，是否都校验了数据归属（SQL 中追加 userId）？ | ☐ | | D2 | 我开发的所有操作接口（增删改），是否都校验了操作权限？ | ☐ | | D3 | 是否有接口仅靠前端隐藏按钮来控制权限？ | ☐ | | D4 | 我是否使用了参数化查询（防止 SQL 注入的同时也防止通过注入绕过权限）？ | ☐ | | D5 | 返回给前端的数据，是否做了敏感字段脱敏？ | ☐ | | D6 | 我的代码中是否有直接从 Request 参数中取 userId 并查询的写法？ | ☐ | | D7 | 批量操作接口是否有数量限制和数据范围限制？ | ☐ | | D8 | 我是否复核了权限拦截器配置，确保新接口被覆盖？ | ☐ |

8.2 测试人员自查清单

| 编号 | 自查项 | 是否完成 | | — | — | — | | T1 | 是否对每个查询接口都做了水平越权测试（修改 ID 参数）？ | ☐ | | T2 | 是否对每个操作接口都做了垂直越权测试（低权限调高权限接口）？ | ☐ | | T3 | 是否测试了未登录直接访问需要登录的接口？ | ☐ | | T4 | 是否测试了 ID 遍历——连续请求不同 ID，观察返回是否一致属于当前用户？ | ☐ | | T5 | 是否测试了批量请求——并发发送多个不同 ID 的请求？ | ☐ | | T6 | 是否测试了管理员接口的访问控制（普通用户能否直接调用）？ | ☐ | | T7 | 是否扫描了生产环境的 Swagger/Actuator/调试页面？ | ☐ | | T8 | 是否在测试报告中记录了每个接口的越权测试结果？ | ☐ |

8.3 运维/安全人员自查清单

| 编号 | 自查项 | 是否完成 | | — | — | — | | O1 | 生产环境是否关闭了所有调试端点（Swagger, Actuator, Druid 监控等）？ | ☐ | | O2 | 后台管理系统是否限制了访问 IP（或仅通过 VPN 访问）？ | ☐ | | O3 | 是否配置了访问日志，记录所有越权尝试（403 响应）？ | ☐ | | O4 | 是否设置了越权告警规则（同一用户短时间内大量 403）？ | ☐ | | O5 | 是否定期进行越权专项渗透测试？ | ☐ | | O6 | 新建接口上线前，是否有越权安全检查卡控？ | ☐ |

九、总结

扫码参与考试

下篇预告： 模块四将讲解 跨站脚本（XSS）与跨站请求伪造（CSRF） 漏洞。这两种漏洞虽然不直接攻击数据库，但可以劫持用户的浏览器、冒用用户身份发起操作，在银行支付、转账等场景中危害极大。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：401 Unauthorized H H《金融行业信息安全培训课程（三）: 越权访问漏洞详解-文末考试》