本文目录导读：
权限缺失漏洞（也称为越权漏洞或权限管理漏洞）是Web应用中最常见且危害最大的漏洞之一,它通常分为两类：
- 水平越权：普通用户A访问了普通用户B的数据（如查看别人的订单）。
- 垂直越权：普通用户执行了管理员的操作（如普通用户访问后台管理页面）。
修复的核心思路是：后端每个涉及数据操作或敏感操作的接口，都必须对当前用户的身份和权限进行严格校验，不能依赖前端传参的ID或隐藏按钮。
以下是详细的修复步骤与最佳实践：
第一阶段：基础防御（后端强制校验）
所有修复都必须发生在后端,前端只能作为辅助。
修复水平越权（数据对象级别）
问题根源：后端直接使用客户端传来的用户ID（如/api/order?id=1001）查询数据,而没有校验这个订单是否属于当前登录用户。
修复方案：
- 从Session/Token中获取用户身份：永远不要从请求参数中获取当前用户是谁。
- 错误做法：
SELECT * FROM orders WHERE order_id = req.body.userId - 正确做法：
SELECT * FROM orders WHERE order_id = req.params.id AND user_id = session.userId
- 错误做法：
- 使用用户上下文：在处理请求前,将解析出的用户ID存储在请求上下文中。
代码示例（Node.js + Express）：
// 错误：水平越权
app.get('/api/order/:id', (req, res) => {
const order = db.query(`SELECT * FROM orders WHERE id = ${req.params.id}`);
res.send(order); // 任何人都可以查任何订单
});
// 正确：修复后
app.get('/api/order/:id', (req, res) => {
const currentUserId = req.session.userId; // 从Session或JWT中拿
const order = db.query(`SELECT * FROM orders WHERE id = ? AND user_id = ?`, [req.params.id, currentUserId]);
if (!order) return res.status(403).send('无权访问');
res.send(order);
});
修复垂直越权（功能级别）
问题根源：前端隐藏了“删除用户”按钮,但后端没有校验当前用户是否为管理员。
修复方案：
- 角色与权限矩阵：数据库或配置中定义用户角色（如
user,admin,superadmin）。 - 中间件校验：为敏感接口（如删除、修改配置）编写专门的权限校验中间件。
代码示例（Java Spring Security / PHP 中间件）：
@PreAuthorize("hasRole('ADMIN')") // 注解方式
@DeleteMapping("/api/users/{id}")
public Result deleteUser(@PathVariable Long id) {
// 只有管理员才能调用
userService.delete(id);
}
第二阶段：进阶防御（纵深防御）
避免IDOR（不安全的直接对象引用）
不要直接暴露数据库自增ID（如订单号、用户ID）给客户端。
- 方案：使用UUID、哈希ID或经过对称加密的ID。
- 效果：如果用户强行扫描ID（如
order_id=1001, 1002），由于无法猜测UUID（如f47ac10b-58cc-4372-a567-0e02b2c3d479）,攻击难度大幅提升。
服务端参数校验
永远不要信任客户端发来的参数。
- 白名单机制：只允许特定的字段被修改。
- 错误：
UPDATE users SET ${req.body.field} = ${req.body.value} - 正确：只允许
nickname,avatar字段被修改，拒绝role,balance字段。
- 错误：
- 防提权修改：在更新用户资料时，强制从Session中获取
user_id，拒绝客户端发来的user_id参数。
统一权限网关（大型系统）
在微服务架构或大型应用中，使用独立的API网关或权限中心。
- 所有请求先经过网关，网关根据URL模式（如
/api/admin/*）自动校验用户Token中的角色。 - 这样即使某个微服务代码疏忽了,网关也能拦截掉非管理员请求。
第三阶段：自动化检测与审计
自动化修复验证
- 集成SAST（静态应用安全测试）：在CI/CD流水线中运行代码扫描工具（如SonarQube、Fortify）,自动发现缺失权限校验的接口。
- 动态扫描：使用工具（如Burp Suite）模拟攻击,测试所有接口是否被越权。
新增接口必须经过权限评审
制定研发规范：任何新增的API接口，必须包含是否公开、是否需要登录、是否需要特定角色的注释，并在代码审查中强制检查。
常见的坑与误区
| 错误做法 | 正确做法 |
|---|---|
前端用 v-if="isAdmin" 隐藏按钮，后端不校验 |
后端必须独立校验，前端只是UI优化 |
在URL路径中传 user_id 用于查询 |
从服务器Session中获取 user_id |
| 使用自增ID作为资源标识符 | 使用UUID或加密ID |
| 仅校验“GET”请求，“POST/PUT”请求不校验 | 所有HTTP方法都需要校验 |
校验逻辑写在SQL语句中靠 WHERE 子句 |
业务逻辑中先校验身份，再执行数据库操作 |
| 简单的JWT Token（如只存用户名） | Token中包含角色、过期时间，并验证签名 |
修复流程清单
- 确认身份：所有接口必须能识别当前用户（从Token/Session中取）。
- 资源归属校验：在操作任何数据（订单、文章、用户资料）前，比较资源所属用户ID是否等于当前用户ID。
- 权限校验：对于管理后台或敏感功能,调用专门的权限函数进行判断。
- 参数清洗：强制
user_id从服务端获取,拒绝客户端传入。 - 审计：使用自动化工具扫描未覆盖的接口，并纳入Code Review标准。
修复权限缺失漏洞没有银弹，核心在于“永远不信任客户端”，且“每个接口的每次调用都要明确知道调用者是谁、他有权干什么”。
