课程笔记：访问控制与权限访问漏洞
课程名称：计算机网络应用 核心摘要：本讲围绕 Web 应用中的访问控制展开，系统讲解权限的本质（能力）、基于 URL 与基于数据两类访问控制的区别，重点剖析**垂直越权（功能权限）与水平越权（数据权限）**两大类漏洞的成因、表设计原理（RBAC 五表模型）以及防护方案，强调最小权限原则与业务+安全综合设计的思想。
一、 核心概念与原理
1.1 权限的本质
- 权限 = 能力：用户登录系统后能做什么、能访问哪些数据、能进入哪些菜单。
- 权限系统设计是安全设计的核心问题；权限控制不到位，系统将面临基础且灾难性的攻击。
- 任何系统（传统单体项目、微服务项目）都必须有自己的权限系统设计，但实际开发中多以二次开发或采购现成权限管理系统为主，业务团队通常只针对业务模块开发。
1.2 访问控制的两个方向
Web 应用中的访问控制通常针对两个方向，二者需大颗粒度与细粒度相结合：
| 控制方向 | 别名 | 颗粒度 | 控制对象 | 实现难度 |
|---|---|---|---|---|
| 基于 URL 的访问控制 | 基于菜单的访问控制 / 垂直权限 / 功能权限 | 大颗粒度 | 哪些菜单/URL 可访问 | 简单，过滤器或安全框架即可完成 |
| 基于数据的访问控制 | 数据权限 / 水平权限 | 细粒度 | 可访问哪些具体数据行/列 | 较难，依赖业务细节，无统一框架 |
1.3 越权访问漏洞分类
- 垂直越权（Vertical Privilege Escalation）：又称功能权限漏洞，对应基于 URL 访问控制失效，普通用户获取管理员功能权限。
- 水平越权（Horizontal Privilege Escalation）：又称数据权限漏洞，对应基于数据访问控制失效，同角色用户互相操作对方私有数据。
- 未授权访问：未登录即访问应受保护资源。
二、 技术细节与协议分析
2.1 基于 URL 访问控制的表设计（RBAC 五表模型）
设计一套完整的权限管理系统，需要以下五张表：
| 序号 | 表名 | 作用 | 关键字段 |
|---|---|---|---|
| 1 | 用户表 | 存储系统用户信息 | user_id、user_name |
| 2 | 角色表 | 定义不同角色 | role_id、role_name |
| 3 | 资源表（菜单表/URL表） | 定义可访问的 URL/菜单 | resource_id、url、menu_name |
| 4 | 用户-角色关系表 | 维护用户与角色的多对多关系 | user_id、role_id |
| 5 | 角色-资源关系表 | 维护角色与资源的多对多关系 | role_id、resource_id |
关系链路：用户表 → 用户-角色关系表 → 角色表 → 角色-资源关系表 → 资源表，最终定位某用户可访问哪些 URL。
特殊场景示例：张三同时是 IT 部门安全管理员与开发一部的开发工程师，需通过"用户-角色关系表"维护一个用户对应多个角色的关系。
2.2 RBAC（基于角色的访问控制）
- 全称：Role-Based Access Control，简称 RBAC。
- 核心思想：虽有大量用户，但真正决定用户能访问什么资源的是其角色，而非用户本身。
- 最终表现形式：某用户可以访问哪些 URL。
- 角色 = 权限的集合：一个角色对应一组可访问的资源（URL/菜单）。
- 不同角色锁定不同权限，例如论坛中的 admin / 普通用户 / 匿名用户；传统项目中的管理员、财务人员、Boss 等。
| 角色 | 典型权限 |
|---|---|
| admin | 功能节点管理、日志管理、用户管理、角色管理 |
| 普通用户 | 浏览、评论，仅能删除自己的内容 |
| 匿名用户 | 仅浏览 |
| 财务人员 | 支出、薪资、报税 |
| Boss | 数据汇总性查看 |
- 主流框架：早期多用 Shiro；企业（含 Spring 生态）目前多用 Spring Security，其底层即基于 RBAC 模型处理权限管理与鉴权问题。
2.3 垂直越权漏洞分析
| 维度 | 说明 |
|---|---|
| 漏洞名称 | 垂直越权 / 功能权限漏洞 / 基于 URL 访问控制失效 |
| 成因 | 服务端（过滤器）未校验"角色-URL"匹配关系，也未使用安全框架做权限管理与鉴权；仅在前端隐藏部分功能菜单 |
| 攻击方式 | 攻击者略懂开发命名规范，猜测管理员 URL（如 /admin/user/list、/admin/role/manage），直接访问即获得管理员权限 |
| 危害 | 普通用户获得管理员权限，达成权限提升（越权）目的 |
| 防护方案 | 对任何业务相关 URL，每次访问时都判定该用户是否拥有此 URL 访问权限；推荐使用 Spring Security 等安全框架，否则至少在访问任何 URL 前加入鉴权过滤器 |
2.4 水平越权漏洞分析
| 维度 | 说明 |
|---|---|
| 漏洞名称 | 水平越权 / 数据权限漏洞 / IDOR（不安全的直接对象引用）/ 基于数据访问控制失效 |
| 成因 | Web 应用接收用户访问/修改某条数据时，未判断当前用户是否可以操作该条记录（数据权限控制不足） |
| 业务场景 | 同部门张三、李四均有"线索管理"访问权限（垂直权限已控制），但张三只能操作张三的线索、李四只能操作李四的线索（需数据权限控制） |
| 攻击方式 | 张三通过篡改请求参数（如记录 id），删除/查看/修改李四的线索信息 |
| 危害 | 同角色用户互相越权操作私有数据，违背业务需求 |
| 防护方案 | 根据用户 id 做好数据级别权限控制；增删改查时先做会话验证，校验该数据是否属于当前用户 id；具体问题具体分析，无统一框架可一次性完美解决 |
2.5 数据权限的细化分类
数据权限（水平权限）可进一步细分为行权限与列权限：
| 类型 | 控制对象 | 说明 | 典型场景 |
|---|---|---|---|
| 行权限 | 数据行 | 不同用户可访问不同的数据行；张三只能访问张三的行，管理员可访问所有行 | 内部业务系统（如 CRM 线索管理） |
| 列权限 | 数据列 | 限制可访问的字段；摘要列人人可查，详情列仅 VIP 可看 | 面向大众用户的外部 App / 内容平台 |
三、 实践应用与配置命令
3.1 基于 URL 访问控制的过滤器实现思路
// 过滤器核心校验逻辑（伪代码）
// 1. 用户登录成功后，用户信息存入 Session
// 2. 访问任何 URL 前，过滤器拦截并校验
User user = (User) session.getAttribute("user"); // 从 Session 获取用户
String targetUrl = request.getRequestURI(); // 获取目标 URL
// 3. 通过 用户表 -> 用户-角色关系表 -> 角色表 -> 角色-资源关系表 -> 资源表
// 校验该用户对应的角色是否拥有访问 targetUrl 的权限
boolean hasPermission = authService.checkPermission(user.getId(), targetUrl);
if (hasPermission) {
chain.doFilter(request, response); // 放行
} else {
response.sendError(403, "未授权"); // 返回未授权
}
3.2 水平越权防护的数据级校验思路
// 增删改查前的数据归属校验（伪代码）
Long currentUserId = (Long) session.getAttribute("userId");
Clue clue = clueService.getById(clueId); // 查询待操作数据
// 校验当前数据是否属于当前用户（行权限控制）
if (!clue.getOwnerId().equals(currentUserId)) {
throw new UnauthorizedException("越权访问：无权操作他人数据");
}
// 校验通过后执行 增/删/改 操作
clueService.delete(clueId);
说明：数据权限控制无统一框架，需结合业务场景在业务代码中显式校验数据归属。
3.3 漏洞披露平台参考
- 乌云（WooYun）：漏洞披露平台，收录各大厂/机构的漏洞案例（如中国金融认证中心某系统未授权访问、涉及内网等），含厂商、作者、提交/修复/公开时间及漏洞描述，便于了解常见漏洞并指导防护。作为合格开发人员，应具备安全意识，关注此类平台。
四、 重点与难点提示
4.1 考点 / 易错点
- 权限的本质是"能力"，访问控制 = 权限控制，归属于访问系统 URL/数据接口的资源访问问题。
- 垂直权限 vs 水平权限 是高频考点，务必区分：
- 垂直权限 = 功能权限 = 基于 URL 访问控制（大颗粒度）。
- 水平权限 = 数据权限 = 基于数据访问控制（细粒度）。
- RBAC 五表模型（用户表、角色表、资源表、用户-角色关系表、角色-资源关系表）是权限系统设计的基础，需能画出关系图并说明数据流向。
- 行权限 vs 列权限：行权限控制"能看哪些行"，列权限控制"能看哪些列"（外部 App 常见，如摘要免费、详情 VIP）。
- IDOR（不安全的直接对象引用） 属于水平越权的典型表现，面试常考。
- 水平越权无统一框架可解，需结合业务做数据级校验；垂直越权可通过 Spring Security / Shiro / 过滤器解决。
4.2 易错点提示
- 仅在前端隐藏菜单 ≠ 权限控制，服务端必须校验。
- 使用安全框架（如 Spring Security）默认只解决垂直权限（URL/功能级），不解决水平权限（数据级）。
- 越权场景与业务需求交织（如张三可查看李四信息但不能修改），需安全 + 业务综合判断，不可一刀切。
- 命名规范虽提升可读性，但也会让攻击者更易猜测管理 URL，不能依赖命名混淆作为安全手段。
4.3 面试高频题
- 什么是垂直越权与水平越权？举例说明二者区别。
- 简述 RBAC 模型及其五张表设计。
- 什么是 IDOR？如何防护？
- 行权限与列权限的区别及应用场景？
- 为什么水平越权难以用统一框架解决？
- 简述最小权限原则及其在权限设计中的应用。
五、 课后疑问/遗留问题
- Spring Security 的具体配置与 RBAC 落地实现细节（本讲仅提及框架名，未展开实战配置）。
- 当一个用户拥有多个角色时，权限是取并集还是做冲突仲裁？实际项目中如何处理角色间的权限重叠与互斥？
- 列权限在数据库层与应用层分别如何落地实现？是否有成熟方案？
- 水平越权的通用化解决方案探索：是否存在基于数据权限中间件 / MyBatis 拦截器 / 数据权限注解的半通用方案？
- 课后建议：访问乌云等漏洞披露平台，查阅真实未授权访问 / 越权访问案例，分析其成因与修复方式。