权限滥用几乎是漏洞清单里最容易被低估的一类尤其是埋在长流程里的越权漏洞往往要在特定步骤组合下才触发。梳理一个典型的订单业务整个取消订单闭环分四步——选择地址、确认商品、填写发票、提交取消申请。前三步都正常第四步后端只认请求体里的orderId压根没校验这个订单是不是当前登录用户自己的。结果一个低权限账号把别人的订单直接取消掉还能看到订单金额和收货地址。这类问题在测试报告里常写成“多步流程越权”本质是权限管理在步骤之间出现了断裂。这篇文章写给两类人一类是做安全测试、想系统排查业务逻辑漏洞的同学另一类是后端开发想搞清楚为什么自己写的接口会被人跨用户操作。我会把越权原理、多步流程里的攻击视角、手工检测工序、修复方案和排查坑位一次性讲清楚内容偏实操尽量不堆概念。你可以直接拿这套思路去梳理自己的项目也可以把它当成代码评审时的检查清单。1. 越权漏洞的本质为什么多步流程里藏着更多问题很多人第一次接触越权时都是从单个接口的“替换ID试试”开始的。比如把一个请求里的userId从1001改成1002发现返回了别人的资料于是判定为越权。这种单步越权确实好抓但真正让人头疼的是那种需要走完三步、四步才触发的问题因为每一步单独看都“没问题”合到一起就成了一个大洞。1.1 水平越权和垂直越权先分清再往下聊越权通常分成两类多步流程里两类都可能出现而且经常叠加。对比项水平越权垂直越权核心对象同级普通用户不同权限角色典型体现查看、修改、删除其他人的数据普通用户调用管理接口多步流程表现后置步骤没有校验资源归属跳过审批步骤直接执行最终动作危害侧重数据泄露、数据篡改越权操作、权限提升水平越权最经典的形态是不安全的直接对象引用也就是常说的IDOR。前端传了一个资源ID后端拿这个ID直接查库没有校验它是不是属于当前登录用户。垂直越权则更直白一个普通账号可以访问到需要更高角色才能执行的接口比如发起一笔提现正常流程要经过主管审批但攻击者直接调用了提现执行接口。给你一个生活化的类比想象一栋带三道门禁的楼第一道门卫认工牌第二道电梯按楼层第三道房间钥匙。水平越权就是你拿自己的卡刷开了别人家房门垂直越权就是你绕过电梯权限控制直接从天台溜进顶层办公区。多步流程相当于把这三道门拆成了三个独立HTTP请求任何一个环节少校验一把钥匙整栋楼就漏了。1.2 多步流程的问题不在“步骤多”而在信任边界错位开发者在写多步流程的时候脑内逻辑通常是线性的第一步验证登录态第二步验证资源归属后面就默认“这个用户已经通过了”。这种默认在单体页面上也许还能成立但在接口满天飞的移动端和前后端分离架构里每一个请求都是独立抵达后端的后端只能根据当前请求里的参数来判断该做什么。问题就出在这里只要中间某个接口把“归属标识”当作客户端传入值来信任越权就出现了。比如修改手机号流程里第一步校验旧密码第二步提交新手机号。如果第二步的请求体里可以额外传一个userId而后端只用这个userId来定位要改哪个账号那么攻击者把自己的userId换成受害者的就能在不知道受害者旧密码的情况下改掉对方手机号。再往深一层看多步流程还容易出现“步骤间状态缺失”。前端靠页面跳转来维持流程顺序但后端没有保存任何“我走到第几步了”的状态。攻击者完全可以跳过第一步直接发送最后一步的完整请求。在没有流程状态校验的接口面前按钮上写的“下一步”只是一个装饰。1.3 越权为什么比参数注入更让业务头疼SQL注入、命令注入这类漏洞通常一个补丁就能封死。越权不一样它长在业务逻辑里每个流程的校验方式都不一样很难用一套通用规则覆盖。尤其是多步越权它不像单个参数漏洞那样扫一遍就能发现往往需要组合多个步骤才触发自动化工具基本帮不上忙。业务上的后果也分几个层级。轻一点的是水平越权泄露他人隐私比如姓名、电话、住址、订单记录重一点的是越权执行操作比如取消订单、修改收货地址、发起退款、改账号凭证直接造成资金或资产损失。垂直越权则可能让一个普通用户调用到管理员才能使用的接口后续的破坏面就完全不可控了。所以这类漏洞在正式风险评估里通常被定得很高因为它直接踩中了数据完整性和业务逻辑这两个关键点。2. 多步流程越权的典型场景与攻击视角要理解怎么利用先得理解攻击者的思考方式。多步流程在设计和实现上各有不同但攻击者盯上的关键点就那么几个资源主键、流程状态、角色字段。下面我把常见的攻击视角拆成可操作的思路再结合几个业务场景讲清楚。2.1 前端流程只是“纸老虎”接口才是真正的攻击面前端把流程做成多步本意是降低用户误操作率给每个步骤一个确认机会。但对攻击者来说前端只是一个可以跳过的界面。用代理工具抓一遍正常操作就能拿到一串接口路径、请求参数、Cookie和响应结构。比如一个“找回密码”流程表面上要填手机号、收验证码、设新密码实际接口可能就是/api/password/reset/verify和/api/password/reset/confirm两个。攻击者不需要一个步骤一个步骤地点按钮他可以直接把confirm这个接口翻出来看参数。如果确认接口只接收code和newPassword而后端没有把code和具体用户绑定那这就是一个多步流程里的水平越权任何人都可以用一个已知验证码改他的密码。理解了这个视角后面所有检测思路都顺了——永远不为“前端限制了输入”而放心只看服务端到底校验了什么。2.2 攻击者视角跳过、替换、篡改在具体的多步流程里攻击者通常做三件事。第一跳过前置步骤。正常流程是A到B再到C攻击者直接调C。如果C接口没有校验前置状态比如没有验证码校验记录、没有审批通过记录、没有上一步生成的临时会话ID那流程就是虚设的。第二替换关键ID。这是最常见的手法。流程里某个请求携带了资源ID比如订单ID、文件ID、用户ID攻击者把它换成别人的ID看后端是否还能正常返回或执行。替换的ID来源可能是数据包里的明文参数也可能是JSON里的嵌套字段先把所有id、uid、target、resource这类字段都标记出来。第三篡改状态与角色字段。有些系统会把流程状态、用户角色也放在客户端参数里比如step: 3、role: admin、approved: true。这类字段一旦交给前端控制等于把流程安全拱手送人。这三步可以组合使用。真实攻击中攻击者往往先正常走一遍拿完整接口链再针对每一个包含资源标识或状态标识的请求做变异测试最后根据响应差异判断漏洞是否成立。2.3 四个业务场景里最容易被利用的多步越权第一个场景是订单状态流转。以电商为例取消订单正常是“查订单→填原因→确认取消”。后两步的接口往往不是同一个确认取消的接口接收orderId和cancelReason然后直接把订单状态改成已取消。如果后端只校验了“订单存在”和“订单状态是待支付/待收货”却没有校验orderId属于当前登录用户那就意味着登录用户可以取消任意人的订单。类似的问题还会出现在修改收货地址、申请退款、查看物流轨迹等子流程里。第二个场景是账号安全设置。改绑定手机号、改邮箱、改密码这类流程天然是多步骤的因为要先验证旧凭证。典型漏洞是第一步验证完旧密码后后端返回一个verifiedtrue的标记第二步接口直接信任这个标记。可这个标记如果只是客户端可读的响应字段攻击者完全可以伪造。更隐蔽的写法是在第二步请求体里放userId后端用它来定位账号这就回到了IDOR的老路上。第三个场景是文件上传与转存。很多系统先让用户把文件传到临时目录再由用户确认后“转存”到正式目录。转存接口如果接收一个fileToken或tmpFileId却没有核对这个临时文件是谁传的攻击者只要拿到别人的token就能盗取文件内容。我见过一个相册应用上传预览图之后可以“设为封面”封面接口只校验图片ID最后硬生生被人遍历出了一整站的用户头像原图。第四个场景是审批流与工作流。发起申请、主管审批、执行操作这三个动作在系统里通常是三个独立接口。审批接口有权限校验但执行接口如果只校验“任务存在”就继续往下跑攻击者可以先正常发起一条申请拿到任务ID再绕开审批接口直接调用执行接口。垂直越权往往就藏在这种“最后一公里”的位置。3. 检测与复现多步越权手工测试的完整工序手工测多步越权最忌讳上来就拿工具扫参数。规矩是先完整走一遍业务流程把接口清单和参数关系摸清楚再针对每个关键点做定向验证。整个过程不复杂但需要耐心。3.1 第一步先把流程拆成“接口清单”用抓包代理或者浏览器开发者工具把一个正常用户从入口到结束的所有请求记录下来。不要只关注页面展示的内容要把每个请求的方法、路径、参数、请求头、返回值都存下来。特别是那些在流程“中间节点”发生的请求它们往往承担了状态校验和资源ID传递的任务。举个例子一个修改绑定手机号的流程可能长这样登录后请求发送验证码到旧手机号POST /api/security/send_code提交旧手机号验证码POST /api/security/verify_old发送新手机号验证码POST /api/security/send_new_code提交新手机号并完成绑定POST /api/security/bind_new手工测试时可以先用命令行工具直接重放其中一个请求体会一下去掉前端之后每个接口单独面对攻击者时是什么状态。curl -i -X POST https://app.example.com/api/security/bind_new \ -H Cookie: sessionyour_session_id \ -H Content-Type: application/json \ -d {userId: 10001, newPhone: 13800000000, newCode: 123456}这一步不急着看漏洞先把接口的“可重复调用性”和“参数独立性”摸清楚。很多后端接口即使前端流程没走完单独调用仍然有效这本身就是流程设计上的风险点。3.2 第二步给每个接口做一次“归属审计”把接口清单整理完之后逐个问下面几个问题。这个接口最终操作了数据库里的哪张表关键资源的主键来自路径、查询参数、请求体还是来自服务端会话服务端有没有显式取出当前登录用户并用它过滤资源有没有只校验“资源存在性”而没校验“资源归属”流程状态是存在服务端还是由客户端通过参数传递这些问题里最重要的就是最后两个。我见过太多接口在代码开头写了一句“if order exists”就继续往下走却完全没有判断“order.owner_id current_user.id”。这种代码在单个接口评审时很难发现但组合进一个多步流程里就成了越权的通道。如果你有源码权限直接搜findById、getById这类方法再往上层看有没有调用鉴权函数。如果没有源码就靠请求参数和响应差异来判断。凡是响应里带着完整业务数据的接口都值得重点关注。3.3 第三步双账号交叉验证别用单账号自嗨单账号测试最大的问题是“看起来一切正常”因为校验逻辑可能针对当前用户是通的只有换成别人的资源ID才会露出马脚。正确的做法是准备两个账号A和B用A走完整个流程然后把关键请求里的资源ID替换成B的资源再观察返回是否仍然成功。具体操作步骤是这样用A账号登录正常走到流程的倒数第二步记录下最后一步请求的完整数据包。另起会话登录B账号从业务里找到一条属于B的资源比如订单号、文件ID或用户ID。把A的请求包里的资源ID改成B的其余内容不要动重新发送。对比A和B会话下的响应内容。如果B尝试访问A的资源时后端返回了正常数据或成功状态说明水平越权成立。再单独测试“跳过前置步骤”不执行流程前几步直接发送最后一步的请求看后端是否因为缺少验证记录而拒绝。两个测试账号最好用完全不同的手机号、邮箱注册避免服务端误按手机号判断归属。我习惯在请求里加一个随机参数比如?debugrandom123防止浏览器或代理缓存干扰判断。3.4 用脚本批量跑一遍别靠肉眼硬看如果业务里资源ID是纯数字且存在递增规律手工一个一个换ID效率太低。这时候可以写个简单的脚本遍历一批ID再对比响应状态码、返回体长度或者特定字段值快速定位可疑的越权点。下面这个例子用Python的requests库演示了思路务必在授权测试环境下运行。import requests s requests.Session() s.post(https://app.example.com/api/login, json{ username: user_a, password: test_password }) # 这里填一个目标范围内的订单ID列表 order_ids [10001, 10002, 10003, 10004, 10005, 10006] for order_id in order_ids: r s.post(https://app.example.com/api/order/cancel, json{ orderId: order_id, reason: 自动化越权验证 }) print(order_id, r.status_code, len(r.content), r.text[:120])如果脚本跑下来发现多个不同ID都返回了相同的成功状态码和相近的响应长度那通常意味着后端根本没有按归属过滤。不过要注意这个脚本一旦执行就是真实业务操作所以请只在测试环境或自己创建的数据集上跑改状态类接口务必慎用。4. 修复方法把校验搬回服务端锁死流程状态检测出漏洞只是第一步真正值钱的是修复方案。多步越权的修复没有一个万能补丁但有几条工程化的原则可以覆盖绝大多数场景。4.1 统一“归属校验”原语写在所有变更操作之前最好的办法不是让每个开发自己写if判断而是封装一个统一的归属校验函数所有涉及资源ID的接口在动手改库之前都必须调用它。伪代码大概长这样def assert_owner(model, resource_id, current_user_id): obj db.session.query(model).filter_by(idresource_id).first() if obj is None: raise ResourceNotFound() if obj.owner_id ! current_user_id: raise PermissionDenied()订单接口调用时传Order模型文件接口传File模型用户资料接口传UserProfile模型。这个函数同时覆盖了“资源不存在”和“资源不属于当前用户”两种情况避免攻击者通过不同报错文案来探测数据是否存在。关键点是不能只查resource_id一定要连带owner_id一起查出来再比对。4.2 用一次性流程令牌锁住步骤顺序针对“跳过中间步骤直接调最后一步”的问题比较成熟的方案是引入一次性流程令牌。第一步校验通过后后端在Redis或内存里生成一个随机token并保存它的状态、用户、目标和过期时间然后把这个token返回给前端。后续的每一步请求都必须携带这个token后端先验证token是否存在、是否匹配当前用户、状态是否处于正确的前置节点。# 伪代码第二步校验流程令牌 flow redis.get(fflow:{token}) if not flow: abort(403) if flow[user_id] ! current_user.id: abort(403) if flow[step] ! old_phone_verified: abort(403)token在流程成功完成后立刻删除任何一步失败也删除不允许重复使用。这样一来攻击者即使拿到了最后一步的接口地址缺少token也什么都干不了。注意token一定要用高熵随机串别用自增数字或者可预测的时间戳。4.3 会话承载上下文别再让前端传“我是谁”多步流程越权里最普遍的一个坏习惯就是把当前用户、当前角色、当前步骤这类“上下文信息”放进前端可控的请求体里。正确的做法是当前用户永远从服务端登录态解析前端只传操作目标比如orderId、fileId并且后端拿到目标ID之后立即用当前用户的身份去过滤它。比如“修改订单收货地址”的接口用户只需要传orderId和newAddress后端内部再跑一遍SELECT * FROM orders WHERE id ? AND user_id ?查不到就直接抛异常。这就把“这个订单是否属于当前用户”的责任完全留在了服务端而不是交给前端自觉。4.4 自动化防线代码扫描与接口回归测试修复之后还需要防止问题再次出现。代码扫描层面可以给静态分析工具加一条规则凡是接口函数中使用了请求体里的ID字段作为查询条件且函数体内没有调用鉴权或归属校验函数就标记为风险。虽然会有误报但能逼着开发人员思考“这个ID能不能被客户端随便改”。接口回归测试层面把双账号交叉验证固化成自动化用例。每个涉及资源ID的核心接口都用两个不同账号跑一遍“A账号操作B账号资源”的用例断言返回403或业务失败。这一步投入不大但对防止回归非常有效。团队规模允许的话还可以在数据库层面做行级安全策略让所有查询默认带上当前用户的条件作为纵深防御的最后一层。5. 常见踩坑与排查技巧实录测试和修复多步越权的时候总有几个坑反复出现。有的是开发习惯导致的有的是测试环境干扰导致的下面是几个我遇到过的典型问题。5.1 最容易被忽略的“前置校验假象”有一种代码长得很安全第一步校验旧密码通过了才允许走第二步。但实现上第一步通过后并没有在后端保存可信状态而是给前端返回了一个verifiedtrue的字段。第二步接口的逻辑是“如果请求体里verified为true就允许修改”。攻击者直接在第二步的请求体里填verifiedtrue等于骗过了整个流程。判断一个校验是否真实就看它依赖的数据到底由谁产生。服务端自己保存在会话或数据库里的状态才能信客户端能改的字段都不能作为安全依据。在代码评审时看到if request.form.get(verified) true这种写法可以直接判定为高危。5.2 缓存和重复请求带来的误判检测过程中最大的干扰因素不是逻辑而是缓存。浏览器缓存、代理缓存、CDN缓存都可能让你看到一套和实际逻辑不符的响应。比如你替换ID后返回了一个疑似别人的页面结果可能只是某个GET接口被缓存了而不是越权。处理方法是给测试请求加随机查询参数清空缓存之后再验证同一场景重复请求三次以上结果一致才下结论。POST接口通常不会被缓存但一些系统用了自定义的响应缓存中间件所以不要默认它不会缓存。另一种干扰来自并发重复请求你连续发了两次取消订单请求第一次成功第二次因为订单已取消而返回失败这可能被误判为“第二次是越权失败”实际上只是业务流程本身不幂等。5.3 为什么移动端接口比网页端更容易出现多步越权多步越权在移动端App里出现的频率明显比传统网页端高。原因挺现实App屏幕小一个复杂流程往往被拆成四五个小接口而且很多接口是给“内部复用”设计的鉴权字段反而不如Web端完整。加上不少移动端接口为了省流量会返回精简字段前端状态靠本地存储维持后端如果不做校验流程就是全裸的。我对比过同一套业务在Web端和App端的接口实现Web端走页面跳转、每步都有权限检查App端因为要做交互优化把校验逻辑挪到了前端控制器里。结果一个订单查询接口在Web端是安全的换成App端的接口直接可以用任意订单号查别人信息。所以在测试或做安全评审时不要只盯着Web端移动端接口更应该逐条审计。5.4 排查技巧速查表现象可能原因排查方法修复要点多步流程只走最后一步也能成功后端没有保存流程状态跳过中间步骤直接重放末步请求引入一次性流程令牌服务端校验状态替换ID后仍能访问他人资源资源归属校验缺失双账号交叉替换关键ID增加统一归属校验连带owner_id比对响应里带他人的字段数据查询未按当前用户过滤检查接口是否使用了请求体ID直接查库用session解析当前用户再过滤资源前端返回verified/role标记客户端参数参与安全判断修改请求体里状态字段看是否生效安全状态只保存在服务端会话同一接口不同用户返回差异归属校验不完整或缓存干扰加随机查询串重复验证统一校验逻辑并清理缓存这张表是我每次复盘越权问题时的检查模板你也可以直接抄走遇到类似现象先对号入座再深挖具体实现。最后说点个人体会。多步流程里的越权往往不是某个程序员有意留下后门而是因为大家默认“上一步验证过这一步就不用再查”。可HTTP请求本质上是无状态的前端流程再漂亮也管不住攻击者直接拿报文来问。我在实际项目里处理这类问题第一反应不是教开发补两个if而是先把流程状态机画出来看看哪些校验被放在了客户端、哪些参数可以随意更改先把信任边界理顺再谈加防御。这个思路比到处打补丁有用得多也希望对你接下来的排查和开发工作有帮助。
权限滥用几乎是漏洞清单里最容易被低估的一类尤其是埋在长流程里的越权漏洞往往要在特定步骤组合下才触发。梳理一个典型的订单业务整个取消订单闭环分四步——选择地址、确认商品、填写发票、提交取消申请。前三步都正常第四步后端只认请求体里的orderId压根没校验这个订单是不是当前登录用户自己的。结果一个低权限账号把别人的订单直接取消掉还能看到订单金额和收货地址。这类问题在测试报告里常写成“多步流程越权”本质是权限管理在步骤之间出现了断裂。这篇文章写给两类人一类是做安全测试、想系统排查业务逻辑漏洞的同学另一类是后端开发想搞清楚为什么自己写的接口会被人跨用户操作。我会把越权原理、多步流程里的攻击视角、手工检测工序、修复方案和排查坑位一次性讲清楚内容偏实操尽量不堆概念。你可以直接拿这套思路去梳理自己的项目也可以把它当成代码评审时的检查清单。1. 越权漏洞的本质为什么多步流程里藏着更多问题很多人第一次接触越权时都是从单个接口的“替换ID试试”开始的。比如把一个请求里的userId从1001改成1002发现返回了别人的资料于是判定为越权。这种单步越权确实好抓但真正让人头疼的是那种需要走完三步、四步才触发的问题因为每一步单独看都“没问题”合到一起就成了一个大洞。1.1 水平越权和垂直越权先分清再往下聊越权通常分成两类多步流程里两类都可能出现而且经常叠加。对比项水平越权垂直越权核心对象同级普通用户不同权限角色典型体现查看、修改、删除其他人的数据普通用户调用管理接口多步流程表现后置步骤没有校验资源归属跳过审批步骤直接执行最终动作危害侧重数据泄露、数据篡改越权操作、权限提升水平越权最经典的形态是不安全的直接对象引用也就是常说的IDOR。前端传了一个资源ID后端拿这个ID直接查库没有校验它是不是属于当前登录用户。垂直越权则更直白一个普通账号可以访问到需要更高角色才能执行的接口比如发起一笔提现正常流程要经过主管审批但攻击者直接调用了提现执行接口。给你一个生活化的类比想象一栋带三道门禁的楼第一道门卫认工牌第二道电梯按楼层第三道房间钥匙。水平越权就是你拿自己的卡刷开了别人家房门垂直越权就是你绕过电梯权限控制直接从天台溜进顶层办公区。多步流程相当于把这三道门拆成了三个独立HTTP请求任何一个环节少校验一把钥匙整栋楼就漏了。1.2 多步流程的问题不在“步骤多”而在信任边界错位开发者在写多步流程的时候脑内逻辑通常是线性的第一步验证登录态第二步验证资源归属后面就默认“这个用户已经通过了”。这种默认在单体页面上也许还能成立但在接口满天飞的移动端和前后端分离架构里每一个请求都是独立抵达后端的后端只能根据当前请求里的参数来判断该做什么。问题就出在这里只要中间某个接口把“归属标识”当作客户端传入值来信任越权就出现了。比如修改手机号流程里第一步校验旧密码第二步提交新手机号。如果第二步的请求体里可以额外传一个userId而后端只用这个userId来定位要改哪个账号那么攻击者把自己的userId换成受害者的就能在不知道受害者旧密码的情况下改掉对方手机号。再往深一层看多步流程还容易出现“步骤间状态缺失”。前端靠页面跳转来维持流程顺序但后端没有保存任何“我走到第几步了”的状态。攻击者完全可以跳过第一步直接发送最后一步的完整请求。在没有流程状态校验的接口面前按钮上写的“下一步”只是一个装饰。1.3 越权为什么比参数注入更让业务头疼SQL注入、命令注入这类漏洞通常一个补丁就能封死。越权不一样它长在业务逻辑里每个流程的校验方式都不一样很难用一套通用规则覆盖。尤其是多步越权它不像单个参数漏洞那样扫一遍就能发现往往需要组合多个步骤才触发自动化工具基本帮不上忙。业务上的后果也分几个层级。轻一点的是水平越权泄露他人隐私比如姓名、电话、住址、订单记录重一点的是越权执行操作比如取消订单、修改收货地址、发起退款、改账号凭证直接造成资金或资产损失。垂直越权则可能让一个普通用户调用到管理员才能使用的接口后续的破坏面就完全不可控了。所以这类漏洞在正式风险评估里通常被定得很高因为它直接踩中了数据完整性和业务逻辑这两个关键点。2. 多步流程越权的典型场景与攻击视角要理解怎么利用先得理解攻击者的思考方式。多步流程在设计和实现上各有不同但攻击者盯上的关键点就那么几个资源主键、流程状态、角色字段。下面我把常见的攻击视角拆成可操作的思路再结合几个业务场景讲清楚。2.1 前端流程只是“纸老虎”接口才是真正的攻击面前端把流程做成多步本意是降低用户误操作率给每个步骤一个确认机会。但对攻击者来说前端只是一个可以跳过的界面。用代理工具抓一遍正常操作就能拿到一串接口路径、请求参数、Cookie和响应结构。比如一个“找回密码”流程表面上要填手机号、收验证码、设新密码实际接口可能就是/api/password/reset/verify和/api/password/reset/confirm两个。攻击者不需要一个步骤一个步骤地点按钮他可以直接把confirm这个接口翻出来看参数。如果确认接口只接收code和newPassword而后端没有把code和具体用户绑定那这就是一个多步流程里的水平越权任何人都可以用一个已知验证码改他的密码。理解了这个视角后面所有检测思路都顺了——永远不为“前端限制了输入”而放心只看服务端到底校验了什么。2.2 攻击者视角跳过、替换、篡改在具体的多步流程里攻击者通常做三件事。第一跳过前置步骤。正常流程是A到B再到C攻击者直接调C。如果C接口没有校验前置状态比如没有验证码校验记录、没有审批通过记录、没有上一步生成的临时会话ID那流程就是虚设的。第二替换关键ID。这是最常见的手法。流程里某个请求携带了资源ID比如订单ID、文件ID、用户ID攻击者把它换成别人的ID看后端是否还能正常返回或执行。替换的ID来源可能是数据包里的明文参数也可能是JSON里的嵌套字段先把所有id、uid、target、resource这类字段都标记出来。第三篡改状态与角色字段。有些系统会把流程状态、用户角色也放在客户端参数里比如step: 3、role: admin、approved: true。这类字段一旦交给前端控制等于把流程安全拱手送人。这三步可以组合使用。真实攻击中攻击者往往先正常走一遍拿完整接口链再针对每一个包含资源标识或状态标识的请求做变异测试最后根据响应差异判断漏洞是否成立。2.3 四个业务场景里最容易被利用的多步越权第一个场景是订单状态流转。以电商为例取消订单正常是“查订单→填原因→确认取消”。后两步的接口往往不是同一个确认取消的接口接收orderId和cancelReason然后直接把订单状态改成已取消。如果后端只校验了“订单存在”和“订单状态是待支付/待收货”却没有校验orderId属于当前登录用户那就意味着登录用户可以取消任意人的订单。类似的问题还会出现在修改收货地址、申请退款、查看物流轨迹等子流程里。第二个场景是账号安全设置。改绑定手机号、改邮箱、改密码这类流程天然是多步骤的因为要先验证旧凭证。典型漏洞是第一步验证完旧密码后后端返回一个verifiedtrue的标记第二步接口直接信任这个标记。可这个标记如果只是客户端可读的响应字段攻击者完全可以伪造。更隐蔽的写法是在第二步请求体里放userId后端用它来定位账号这就回到了IDOR的老路上。第三个场景是文件上传与转存。很多系统先让用户把文件传到临时目录再由用户确认后“转存”到正式目录。转存接口如果接收一个fileToken或tmpFileId却没有核对这个临时文件是谁传的攻击者只要拿到别人的token就能盗取文件内容。我见过一个相册应用上传预览图之后可以“设为封面”封面接口只校验图片ID最后硬生生被人遍历出了一整站的用户头像原图。第四个场景是审批流与工作流。发起申请、主管审批、执行操作这三个动作在系统里通常是三个独立接口。审批接口有权限校验但执行接口如果只校验“任务存在”就继续往下跑攻击者可以先正常发起一条申请拿到任务ID再绕开审批接口直接调用执行接口。垂直越权往往就藏在这种“最后一公里”的位置。3. 检测与复现多步越权手工测试的完整工序手工测多步越权最忌讳上来就拿工具扫参数。规矩是先完整走一遍业务流程把接口清单和参数关系摸清楚再针对每个关键点做定向验证。整个过程不复杂但需要耐心。3.1 第一步先把流程拆成“接口清单”用抓包代理或者浏览器开发者工具把一个正常用户从入口到结束的所有请求记录下来。不要只关注页面展示的内容要把每个请求的方法、路径、参数、请求头、返回值都存下来。特别是那些在流程“中间节点”发生的请求它们往往承担了状态校验和资源ID传递的任务。举个例子一个修改绑定手机号的流程可能长这样登录后请求发送验证码到旧手机号POST /api/security/send_code提交旧手机号验证码POST /api/security/verify_old发送新手机号验证码POST /api/security/send_new_code提交新手机号并完成绑定POST /api/security/bind_new手工测试时可以先用命令行工具直接重放其中一个请求体会一下去掉前端之后每个接口单独面对攻击者时是什么状态。curl -i -X POST https://app.example.com/api/security/bind_new \ -H Cookie: sessionyour_session_id \ -H Content-Type: application/json \ -d {userId: 10001, newPhone: 13800000000, newCode: 123456}这一步不急着看漏洞先把接口的“可重复调用性”和“参数独立性”摸清楚。很多后端接口即使前端流程没走完单独调用仍然有效这本身就是流程设计上的风险点。3.2 第二步给每个接口做一次“归属审计”把接口清单整理完之后逐个问下面几个问题。这个接口最终操作了数据库里的哪张表关键资源的主键来自路径、查询参数、请求体还是来自服务端会话服务端有没有显式取出当前登录用户并用它过滤资源有没有只校验“资源存在性”而没校验“资源归属”流程状态是存在服务端还是由客户端通过参数传递这些问题里最重要的就是最后两个。我见过太多接口在代码开头写了一句“if order exists”就继续往下走却完全没有判断“order.owner_id current_user.id”。这种代码在单个接口评审时很难发现但组合进一个多步流程里就成了越权的通道。如果你有源码权限直接搜findById、getById这类方法再往上层看有没有调用鉴权函数。如果没有源码就靠请求参数和响应差异来判断。凡是响应里带着完整业务数据的接口都值得重点关注。3.3 第三步双账号交叉验证别用单账号自嗨单账号测试最大的问题是“看起来一切正常”因为校验逻辑可能针对当前用户是通的只有换成别人的资源ID才会露出马脚。正确的做法是准备两个账号A和B用A走完整个流程然后把关键请求里的资源ID替换成B的资源再观察返回是否仍然成功。具体操作步骤是这样用A账号登录正常走到流程的倒数第二步记录下最后一步请求的完整数据包。另起会话登录B账号从业务里找到一条属于B的资源比如订单号、文件ID或用户ID。把A的请求包里的资源ID改成B的其余内容不要动重新发送。对比A和B会话下的响应内容。如果B尝试访问A的资源时后端返回了正常数据或成功状态说明水平越权成立。再单独测试“跳过前置步骤”不执行流程前几步直接发送最后一步的请求看后端是否因为缺少验证记录而拒绝。两个测试账号最好用完全不同的手机号、邮箱注册避免服务端误按手机号判断归属。我习惯在请求里加一个随机参数比如?debugrandom123防止浏览器或代理缓存干扰判断。3.4 用脚本批量跑一遍别靠肉眼硬看如果业务里资源ID是纯数字且存在递增规律手工一个一个换ID效率太低。这时候可以写个简单的脚本遍历一批ID再对比响应状态码、返回体长度或者特定字段值快速定位可疑的越权点。下面这个例子用Python的requests库演示了思路务必在授权测试环境下运行。import requests s requests.Session() s.post(https://app.example.com/api/login, json{ username: user_a, password: test_password }) # 这里填一个目标范围内的订单ID列表 order_ids [10001, 10002, 10003, 10004, 10005, 10006] for order_id in order_ids: r s.post(https://app.example.com/api/order/cancel, json{ orderId: order_id, reason: 自动化越权验证 }) print(order_id, r.status_code, len(r.content), r.text[:120])如果脚本跑下来发现多个不同ID都返回了相同的成功状态码和相近的响应长度那通常意味着后端根本没有按归属过滤。不过要注意这个脚本一旦执行就是真实业务操作所以请只在测试环境或自己创建的数据集上跑改状态类接口务必慎用。4. 修复方法把校验搬回服务端锁死流程状态检测出漏洞只是第一步真正值钱的是修复方案。多步越权的修复没有一个万能补丁但有几条工程化的原则可以覆盖绝大多数场景。4.1 统一“归属校验”原语写在所有变更操作之前最好的办法不是让每个开发自己写if判断而是封装一个统一的归属校验函数所有涉及资源ID的接口在动手改库之前都必须调用它。伪代码大概长这样def assert_owner(model, resource_id, current_user_id): obj db.session.query(model).filter_by(idresource_id).first() if obj is None: raise ResourceNotFound() if obj.owner_id ! current_user_id: raise PermissionDenied()订单接口调用时传Order模型文件接口传File模型用户资料接口传UserProfile模型。这个函数同时覆盖了“资源不存在”和“资源不属于当前用户”两种情况避免攻击者通过不同报错文案来探测数据是否存在。关键点是不能只查resource_id一定要连带owner_id一起查出来再比对。4.2 用一次性流程令牌锁住步骤顺序针对“跳过中间步骤直接调最后一步”的问题比较成熟的方案是引入一次性流程令牌。第一步校验通过后后端在Redis或内存里生成一个随机token并保存它的状态、用户、目标和过期时间然后把这个token返回给前端。后续的每一步请求都必须携带这个token后端先验证token是否存在、是否匹配当前用户、状态是否处于正确的前置节点。# 伪代码第二步校验流程令牌 flow redis.get(fflow:{token}) if not flow: abort(403) if flow[user_id] ! current_user.id: abort(403) if flow[step] ! old_phone_verified: abort(403)token在流程成功完成后立刻删除任何一步失败也删除不允许重复使用。这样一来攻击者即使拿到了最后一步的接口地址缺少token也什么都干不了。注意token一定要用高熵随机串别用自增数字或者可预测的时间戳。4.3 会话承载上下文别再让前端传“我是谁”多步流程越权里最普遍的一个坏习惯就是把当前用户、当前角色、当前步骤这类“上下文信息”放进前端可控的请求体里。正确的做法是当前用户永远从服务端登录态解析前端只传操作目标比如orderId、fileId并且后端拿到目标ID之后立即用当前用户的身份去过滤它。比如“修改订单收货地址”的接口用户只需要传orderId和newAddress后端内部再跑一遍SELECT * FROM orders WHERE id ? AND user_id ?查不到就直接抛异常。这就把“这个订单是否属于当前用户”的责任完全留在了服务端而不是交给前端自觉。4.4 自动化防线代码扫描与接口回归测试修复之后还需要防止问题再次出现。代码扫描层面可以给静态分析工具加一条规则凡是接口函数中使用了请求体里的ID字段作为查询条件且函数体内没有调用鉴权或归属校验函数就标记为风险。虽然会有误报但能逼着开发人员思考“这个ID能不能被客户端随便改”。接口回归测试层面把双账号交叉验证固化成自动化用例。每个涉及资源ID的核心接口都用两个不同账号跑一遍“A账号操作B账号资源”的用例断言返回403或业务失败。这一步投入不大但对防止回归非常有效。团队规模允许的话还可以在数据库层面做行级安全策略让所有查询默认带上当前用户的条件作为纵深防御的最后一层。5. 常见踩坑与排查技巧实录测试和修复多步越权的时候总有几个坑反复出现。有的是开发习惯导致的有的是测试环境干扰导致的下面是几个我遇到过的典型问题。5.1 最容易被忽略的“前置校验假象”有一种代码长得很安全第一步校验旧密码通过了才允许走第二步。但实现上第一步通过后并没有在后端保存可信状态而是给前端返回了一个verifiedtrue的字段。第二步接口的逻辑是“如果请求体里verified为true就允许修改”。攻击者直接在第二步的请求体里填verifiedtrue等于骗过了整个流程。判断一个校验是否真实就看它依赖的数据到底由谁产生。服务端自己保存在会话或数据库里的状态才能信客户端能改的字段都不能作为安全依据。在代码评审时看到if request.form.get(verified) true这种写法可以直接判定为高危。5.2 缓存和重复请求带来的误判检测过程中最大的干扰因素不是逻辑而是缓存。浏览器缓存、代理缓存、CDN缓存都可能让你看到一套和实际逻辑不符的响应。比如你替换ID后返回了一个疑似别人的页面结果可能只是某个GET接口被缓存了而不是越权。处理方法是给测试请求加随机查询参数清空缓存之后再验证同一场景重复请求三次以上结果一致才下结论。POST接口通常不会被缓存但一些系统用了自定义的响应缓存中间件所以不要默认它不会缓存。另一种干扰来自并发重复请求你连续发了两次取消订单请求第一次成功第二次因为订单已取消而返回失败这可能被误判为“第二次是越权失败”实际上只是业务流程本身不幂等。5.3 为什么移动端接口比网页端更容易出现多步越权多步越权在移动端App里出现的频率明显比传统网页端高。原因挺现实App屏幕小一个复杂流程往往被拆成四五个小接口而且很多接口是给“内部复用”设计的鉴权字段反而不如Web端完整。加上不少移动端接口为了省流量会返回精简字段前端状态靠本地存储维持后端如果不做校验流程就是全裸的。我对比过同一套业务在Web端和App端的接口实现Web端走页面跳转、每步都有权限检查App端因为要做交互优化把校验逻辑挪到了前端控制器里。结果一个订单查询接口在Web端是安全的换成App端的接口直接可以用任意订单号查别人信息。所以在测试或做安全评审时不要只盯着Web端移动端接口更应该逐条审计。5.4 排查技巧速查表现象可能原因排查方法修复要点多步流程只走最后一步也能成功后端没有保存流程状态跳过中间步骤直接重放末步请求引入一次性流程令牌服务端校验状态替换ID后仍能访问他人资源资源归属校验缺失双账号交叉替换关键ID增加统一归属校验连带owner_id比对响应里带他人的字段数据查询未按当前用户过滤检查接口是否使用了请求体ID直接查库用session解析当前用户再过滤资源前端返回verified/role标记客户端参数参与安全判断修改请求体里状态字段看是否生效安全状态只保存在服务端会话同一接口不同用户返回差异归属校验不完整或缓存干扰加随机查询串重复验证统一校验逻辑并清理缓存这张表是我每次复盘越权问题时的检查模板你也可以直接抄走遇到类似现象先对号入座再深挖具体实现。最后说点个人体会。多步流程里的越权往往不是某个程序员有意留下后门而是因为大家默认“上一步验证过这一步就不用再查”。可HTTP请求本质上是无状态的前端流程再漂亮也管不住攻击者直接拿报文来问。我在实际项目里处理这类问题第一反应不是教开发补两个if而是先把流程状态机画出来看看哪些校验被放在了客户端、哪些参数可以随意更改先把信任边界理顺再谈加防御。这个思路比到处打补丁有用得多也希望对你接下来的排查和开发工作有帮助。
