越权漏洞能干什么？下列现很多人第一反应是“改别人密码”“偷看私密聊天记录”。但有些操作，个操过看似跟越权沾边，权漏实际上根本走不通。洞实今天直接拆几个典型场景，下列现看看哪些“越权幻想”纯属想多了。个操过

先看最经典的权漏：水平越权里，你拿A用户的洞实订单号去访问B用户的订单详情。这种接口只要没校验归属，下列现数据就漏了。个操过但反过来，权漏你想通过越权去修改B用户的洞实手机号——这通常做不到。为什么？下列现因为修改手机号这类敏感操作，后端往往会强制要求二次验证，个操过比如短信验证码或支付密码。权漏你就算把请求里的用户ID改成B，服务器也会先检查当前会话是否绑定了B的手机号，没绑就拒绝。这不是权限校验的问题，是业务逻辑里硬性埋了道门槛。

再说个更隐蔽的：垂直越权，普通用户想用管理员接口给自己加个“超级管理员”角色。你抓包把角色字段从“user”改成“admin”，以为能蒙混过关？很多系统的鉴权压根不在参数里，而在服务端从session或token里解析身份。你改请求体里的角色ID，服务器根本不看，它只认当前登录态对应的数据库记录。除非系统本身写了“从前端传角色”这种低级错误，否则这条路堵得死死的。

那什么操作真能通过越权实现？比如批量遍历用户ID，把别人的收货地址拉出来——这常见。或者用同事的工号去查看他的工资条——只要接口没做数据归属校验，也能成。甚至有些系统，你拿A用户的session去调B用户的“删除订单”接口，只要订单号是顺延的，删掉别人的订单也发生过。这些都是真实案例，我见过某电商平台因为一个分页参数没限制，被人把全站用户手机号爬了个遍。

但有个操作，几乎不可能靠越权完成：直接修改别人的登录密码。你想啊，密码重置流程通常分两步，先验证身份（比如旧密码或短信），再设置新密码。越权攻击者连对方的验证码都没有，就算你把请求里的user_id改成目标用户，服务器那关“当前操作者必须持有该用户的验证凭证”就过不去。除非系统把验证步骤和密码更新步骤拆成了两个独立接口，且后者没校验会话——这种设计属于灾难，现实中极少见，因为开发再粗心，也知道密码更新必须绑定当前登录态。

说到底，越权漏洞的本质是“对数据归属和操作范围的校验缺失”，它管的是“你能否操作别人的资源”，但管不了“你能否绕过别人的身份凭证”。换句话讲，越权能让你当“小偷”，但没法让你当“主人”。密码、支付密码、生物特征这类强认证信息，永远不在越权的射程内。

所以下次测试时，别把精力耗在“改密码”这种幻想上。多盯盯那些只校验登录态、不校验归属的查询接口——那才是越权漏洞的重灾区。真实攻击里，十个越权有八个是偷数据，剩下两个是删数据，改密码？那是撞大运撞到设计缺陷才有的福利。