服务器系统权限越权漏洞修复如何做

水平越权修复需校验资源归属，垂直越权修复需拦截功能权限；服务端必须基于会话状态和预设策略独立验证“谁在请求”和“能不能做”，禁用客户端传入的身份或权限标识。

服务器系统权限越权漏洞修复，核心是把“谁在请求”和“能不能做”这两件事真正分开——不能信客户端传来的任何身份或权限标识，所有判断必须基于服务端已确认的会话状态和预设策略。

先区分清楚是哪类越权

水平越权和垂直越权的修复逻辑不同，混用方案容易漏掉关键点：

1. 水平越权：比如普通用户A改了URL里的id=101变成id=102，就看到用户B的数据。本质是资源归属没校验。
2. 垂直越权：比如普通用户直接访问/admin/user-delete接口，删掉了管理员才能操作的账号。本质是功能权限没拦截。

服务端必须做资源归属校验

对涉及具体数据的操作（查、改、删），不能只看用户有没有登录，还要看目标资源是不是属于当前用户：

1. 查询/api/order/123时，从数据库查出订单后再比对order.user_id == current_user.id，不匹配就返回403；
2. 修改用户资料接口，即使参数里带了user_id，也应忽略它，只允许改session里绑定的那个用户；
3. 避免用明文ID暴露资源关系，可考虑用短token替代（如ord_abc7x9），后端再映射到真实ID并校验归属。

接口级权限控制不能靠前端遮掩

菜单隐藏、按钮置灰、路由跳转拦截，全是前端做的，攻击者绕开浏览器直接发请求就能触发漏洞：

1. 每个敏感接口（尤其是POST、DELETE、/admin/路径）都要有服务端鉴权；
2. Java项目可用Spring Security的@PreAuthorize或自定义注解；PHP可用中间件统一拦截；Node.js可用Guard守卫函数；
3. 权限判断要基于角色+能力组合，比如hasRole('ADMIN') || (isOwner() && canEdit())，而不是简单写if (role === 'ADMIN')。

会话与权限状态要实时同步

用户权限变更（如被降权、角色调整、退出登录）后，旧凭证仍能继续访问，等于留了后门：

1. JWT记得加jti（唯一标识）和exp，配合黑名单或短生命周期；
2. Session机制下，权限变更时主动使旧session失效；
3. 敏感操作（如删账号、改密码）前强制二次验证，不只是检查登录态。