权限绕过漏洞是什么
2019年，权限某大型电商平台的绕过安全团队在例行巡检时发现了一个奇怪的现象：一个普通用户账号竟然能访问到管理员后台的订单管理接口。不是漏洞猜测，不是权限理论推演，是绕过实打实的数据包在Burp Suite里躺着。他们花了三天时间回溯代码，漏洞最终定位到一个参数校验逻辑的权限疏漏——前端传了一个 role=user，后端只检查了这个字段有没有值，绕过却忘了验证值的漏洞具体内容。把 user 改成 admin，权限系统就认了。绕过这就是漏洞权限绕过漏洞，一个让安全工程师半夜爬起来改代码的权限东西。
说白了，绕过权限绕过就是漏洞系统本该拦住你的地方没拦住。你是个普通用户，系统应该只让你看自己的订单，结果你通过某种手段看到了别人的；你是个未登录的访客，系统应该把你挡在管理页面外面，结果你改了个URL就进去了。这类漏洞的可怕之处在于，它不需要你破解密码，不需要你拿到加密密钥，只需要你对系统的运作方式比开发者想得更细一点。攻击成本低，危害却直接触及数据核心。
常见的绕过方式有好几种，每一种都对应着开发过程中的某个“想当然”。
水平越权是最普遍的。比如一个查看订单的接口是 /api/order?orderId=1001，你把1001改成1002，如果系统没有校验这个订单属不属于当前登录用户，你就看到了别人的订单。垂直越权则更粗暴——普通用户直接访问管理员接口。有些系统把管理接口放在 /admin/ 路径下，以为前端不显示链接就安全了，但URL是可以直接输入的。还有一种是基于参数的绕过，比如系统检查 isAdmin=false，你把它改成 isAdmin=true，后端如果直接信任这个参数，你就成了管理员。更隐蔽的是路径绕过，比如 /admin/../user/../../admin/config 这种，利用路径解析的差异骗过权限检查中间件。
我见过一个真实案例。某SaaS系统的用户资料接口用JWT做鉴权，token里存了 userId。前端请求时会在URL里带一个 targetUserId，后端逻辑是“如果token里的userId等于targetUserId，就返回自己的资料；否则返回targetUserId对应的公开资料”。听起来没问题？但公开资料接口没有做字段过滤，把邮箱、手机号全返回了。攻击者只需要遍历targetUserId，就能拿到全平台的用户联系方式。一个“公开资料”的权限设计，泄露了本该私密的信息。这种漏洞的根源不是代码写错了，是权限模型设计时就没想清楚“公开”的边界在哪里。
防御这件事，说复杂也复杂，说简单也简单。核心就一条：所有权限校验必须在服务端完成，且必须基于当前会话的身份，而不是客户端传来的任何参数。前端隐藏按钮、URL里加随机字符串、用POST代替GET，这些都不是安全措施，只是用户体验或开发便利。真正的校验逻辑应该像这样——每次请求进来，先从session或token里解出当前用户ID，然后拿这个ID去数据库查“他有没有权限操作目标资源”，而不是信任请求里带的任何身份标识。角色检查也一样，别信 role 参数，去查用户角色表。
另外，别把权限校验写得太分散。一个接口里校验了，另一个忘了，漏洞就出来了。用统一的中间件或拦截器处理鉴权，把“谁在请求”“请求什么资源”“允不允许”这三件事做成标准流程。日志也要记全，谁在什么时间访问了什么接口、带了什么参数、返回了什么状态码。出了事能追溯，平时也能发现异常遍历行为。
权限绕过漏洞不会消失，因为业务逻辑一直在变，新的接口不断加进来，开发者总会有疏忽的时候。但至少可以做到：每次加新接口，先问一句“这个接口谁可以调？怎么保证只有他能调？”把这个问题回答清楚，比事后打补丁强得多。