1. 项目概述什么是垂直越权为什么要用Autorize先聊点实际的。很多测试同学第一次接触越权都是从“改ID看别人数据”开始的——把请求里的user_id1001改成1002发现能拉到别人的订单这是水平越权。但还有一类更隐蔽、更致命的问题叫垂直越权你只是一个普通注册用户却拿着低权限的身份直接调用了管理员的接口比如删除用户、修改配置、查看后台列表。这类漏洞在真实业务里出现频率不低而且危害等级通常直接拉到高危甚至严重。2023版BurpSuite配合社区插件Autorize就能在半自动状态下快速筛查一个应用里是否存在大范围的垂直越权风险。这篇文章不是什么高深的理论课就是一套能直接抄作业的实操流程。我会从越权的基本概念讲起然后是BurpSuite 2023版里如何正确安装配置Autorize再结合一个模拟环境把低权限用户Cookie设置、高权限请求转发、响应比对这几个核心环节完整走一遍。适合刚接触安全测试、对越权测试只有模糊概念的同学也适合做过手工越权测试但觉得效率太低、想搭一套自动检测流程的工程师。Autorize这个插件解决的核心问题很简单手工越权测试时你需要把每一个需要验证的请求都拿出来换一遍低权限Cookie再重放再对比响应。一个后台几十个接口能测到崩溃而且容易漏。Autorize的思路是自动化地完成“换身份重放”这件事——当你用自己的高权限账号正常浏览应用时插件会拦截每一个请求替换成预设的低权限用户身份重新发送一次然后把两次响应放在一起对比。你只需要正常点页面插件替你做了大量重复劳动测试覆盖度比纯手工高得多。2. 环境准备BurpSuite 2023版与Autorize插件安装2.1 BurpSuite 2023版基础环境先说明一点这里所说的2023版指的是BurpSuite 2023.x系列无论是社区版还是专业版Autorize插件都能正常使用。社区版在BApp Store里可以直接安装Autorize功能上没有任何阉割所以不用纠结版本问题。如果你用的是专业版记得检查一下Java环境BurpSuite 2023版要求Java 17以上装了旧版JDK的先把Java升级到17或21否则启动阶段就会报错。安装BurpSuite的过程本身不复杂官网下载对应系统的安装包Windows下直接一路NextmacOS和Linux各自解压运行启动脚本。启动之后会进入项目选择界面这里建议选择Temporary project然后选Use Burp defaults暂时不加载任何配置等插件装好再按需调整。对于越权测试默认配置已经够用。2.2 通过BApp Store安装Autorize打开BurpSuite后切换到Extender标签页再进BApp Store子页签。在搜索框输入Autorize直接在列表里点Install。它会自动下载依赖并完成安装安装完成后左侧会多出一个名为Autorize的标签页。有个判断安装是否成功的细节点击Autorize标签页后如果页面显示一个表格区域和一个日志输出框说明加载成功。有些环境里BApp Store访问比较慢遇到超时就多刷新几次通常是网络原因不是插件本身的问题。2.3 插件界面初识与核心字段装好之后别急着用先把界面上的几个关键字段搞明白。Cookie这里填的是低权限用户的Cookie也就是你希望替换成的身份。Autorize每次重放请求时都会把当前请求的Cookie头换成这个值。加Header可以自定义添加额外的请求头一般用于带Token、Authorization头或者某些自定义签名头的场景。Session不常用默认设置即可。Scope勾选了之后插件只处理在BurpSuite作用域内的请求建议开启避免把无关域名也拉进来测试。Log only勾选后只记录结果不影响实际请求发送。Save和Load配置文件保存与加载换项目后方便恢复。实际使用中你只需要关注Cookie栏和Encode针对URL编码后的Cookie选项。大部分应用Cookie是明文键值对不需要勾Encode但如果你的Cookie里有特殊字符且应用对编码敏感就勾上。3. 核心配置Cookie设置与角色模拟3.1 理解会话切换的原理Autorize的测试逻辑可以拆成一句话用低权限用户的Cookie重放高权限用户的请求看响应是否有区别。所以整个配置的核心就是“高权限请求从哪来”和“低权限身份怎么填”这两个问题。第一个问题高权限请求来源于你自己的操作。你使用高权限账号登录系统然后在浏览器里正常点击功能BurpSuite作为代理捕获这些请求Autorize再拦截下来做二次转发。所以测试前你的浏览器必须通过BurpSuite代理并且当前登录的账号是高权限账号比如管理员账号。第二个问题低权限身份是一个普通用户Cookie。你需要提前注册一个低权限账号登录后从拦截的历史记录里复制Cookie值填入Autorize的Cookie栏。为了保证检测有效这个低权限账号必须和应用里其他普通用户一样不能拥有任何高权限角色标识。3.2 配置低权限用户Cookie打开BurpSuite的HTTP history找到任意一个低权限账号登录后发出的请求定位到Cookie请求头复制整个值不要带Cookie:前缀。回到Autorize界面把这段值粘贴到Cookie输入框。一个常见的误区是只复制了JSESSIONID漏掉了其他Cookie字段。很多应用会有多个Cookie组合才能正确标识身份比如sessionid加csrfToken加role。这里我建议直接复制完整请求头里的原样值避免因为缺字段导致会话失效。还有一个更容易踩的坑Cookie里的roleuser这类字段。有些应用会把角色直接放在Cookie里如果你填的低权限Cookie里带着roleuser而应用恰好信任这段Cookie那越权检测结果就会失真。遇到这种情况测试时最好新建一个干净的低权限测试账号Cookie里只有会话标识没有额外的角色声明。3.3 Scope与URL过滤设置打开BurpSuite的Target标签页在Scope里勾选Use advanced scope control把目标域名加入Include。这一步的意义在于Autorize只处理作用域内的请求你浏览页面时偶尔会加载第三方静态资源、外部统计脚本不设置Scope这些无关请求也会被重放一遍结果列表会变得很脏。在Autorize界面里也勾选Scope复选框确保过滤生效。你还可以在Exclude from scope里排除一些明显无关的路径比如/logout、/static/、.js和.css后缀的资源。排除方式推荐用BurpSuite的Request scope对话框添加支持正则和通配符比直接在Scope里写更清晰。3.4 双Session场景的处理有些系统里高权限和低权限用户会使用不同的认证机制比如高权限用户走OAuth Token低权限用户走Session Cookie。这种场景下Autorize的Cookie替换只处理Cookie头不会自动替换Authorization头。解决办法是在Autorize的Add Header里手动添加一个低权限用户的Authorization头但如果高权限请求本身就带Authorization头BurpSuite在转发时不会自动移除它这样最终发送的请求会同时带两个凭证导致检测失真。稳妥的做法是实在一点的确保高、低权限账号使用同一种认证方式如果应用强制要求Bearer Token那低权限账号也应当有对应的Token值然后利用BurpSuite的Match and Replace规则把请求里的Authorization头替换成低权限Token再把Cookie里的会话字段也替换成低权限Cookie。这样能保证发送出去的请求身份完全是低权限身份。4. 实操过程基于半自动模式的垂直越权测试流程4.1 半自动化的含义与测试策略为什么叫“半自动化”因为Autorize不是全自动扫描器它不会自己爬取全站不会自己构造请求。它的定位是辅助你在手动浏览过程中自动执行身份替换和响应对比。也就是说测试路径的发现仍然依赖你手动点击、手动浏览插件负责的是把每一个请求自动换成低权限身份重放一遍。这种模式的优势很明显它更接近真实业务逻辑。很多越权漏洞藏得深靠爬虫根本扫不出来因为你不知道哪个功能点会触发某个隐藏的管理接口。只有你自己登录高权限账号把后台的菜单、按钮一个个点过去请求才会真实出现在代理里。Autorize的价值就是让这些真实请求全部被重新验证一遍。4.2 完整操作步骤整个流程可以分成以下几步第一步准备两个账号。注册两个测试账号一个高权限管理员一个低权限普通用户。如果系统有预先提供的测试账号直接复用但确保密码可修改方便后续登录。第二步配置代理并登录低权限账号。在浏览器里设置代理为127.0.0.1:8080安装BurpSuite的CA证书然后用低权限账号登录系统随便访问几个页面确认代理能正常抓到请求。第三步将低权限Cookie填入Autorize。在HTTP history里找一条低权限账号发出的干净请求复制完整Cookie值粘贴到Autorize的Cookie栏。第四步切换到高权限账号。在浏览器里退出低权限账号登录高权限账号。注意这一步不需要清空BurpSuite的代理配置只需要切换浏览器里的登录态。第五步打开Autorize开始浏览高权限功能。在Autorize页签点击Enable开关。确保开关是打开状态然后回到浏览器以高权限账号正常操作应用。尽量把所有功能都点一遍尤其是那些涉及增删改查、用户管理、配置管理的操作。第六步观察Autorize结果。每产生一个请求Autorize的表格里会新增一行展示原始请求和重放请求的响应状态码、响应长度、响应内容等对比信息。第七步针对可疑请求做人工复验。这一步最重要。插件只负责初筛最终确认必须由人来判断。找到可疑条目用BurpSuite的Repeater手动重放分别带高权限Cookie和低权限Cookie发送两次对比响应确认真实存在越权风险。4.3 结果分析与越权判断标准Autorize的结果列表默认包含几列#、Method、Host、Path、Status Code、Length、Response Received、High、Low、Finished。其中High和Low分别表示原始请求高权限和重放请求低权限的响应状态码Length是重放请求的响应长度。判断是否存在垂直越权的核心标准是原始请求返回200重放请求也返回200且响应长度接近。这种情况下低权限用户访问高权限接口返回了与高权限用户相同的结果大概率存在越权。但如果原始请求200重放请求返回302、403或401则说明应用正确地拒绝了低权限用户不存在越权。响应长度对比只是辅助判断工具不是绝对依据。有时候响应内容只差几个字节但权限含义完全不一样有时候长度一样但内容是一个统一错误提示页。所以我强调任何可疑结果都要进Repeater人工确认以响应体内容为准不要只看长度。5. 常见问题与排查技巧实录5.1 状态码对比速查表这里整理一份我在实际测试中总结的判断参考表卡片式地列出来方便你对照原始请求状态码重放请求状态码长度对比大概率结论200200几乎一致疑似越权需查看响应体确认200200有明显差异不确定需查看响应内容200302-大概率被拦截重定向到登录页200403-接口存在但已限制权限200401-未认证权限隔离生效200404-可能接口未暴露或已做隐藏处理500200-逻辑异常建议人工确认这里留意一点302并不绝对安全。有些应用会把越权访问重定向到登录页但响应头里的Location泄露了一些不该泄露的信息比如用户列表页的路径。这种信息泄露属于低危不算真正的越权但值得记录。5.2 高权限请求未触发插件重放如果你发现自己浏览了大量页面但Autorize表格里没有新增记录优先排查三件事。第一确认Autorize的Enable开关打开了。这个开关在插件页签顶部状态为绿色才生效。第二确认请求都在作用域内。如果没勾Scope检查一下作用域配置把目标域名加入Include。第三检查浏览器代理是否正常。有些同学用SwitchyOmega这样的代理插件切换到直连后忘了切回来BurpSuite自然抓不到包。可以把浏览器代理设置为全局代理或者打开BurpSuite的Proxy页签看看HTTP history里有没有实时流量。如果history里有新请求但Autorize没反应那就是插件自身的过滤条件问题。还有一个可能你浏览的页面是纯前端渲染请求都是异步加载但因为某种原因请求没走BurpSuite代理比如浏览器启用了某些绕过代理的扩展。这种情况在Chrome里比较常见尤其装了SwitchyOmega后规则混乱时干脆把所有规则删掉只保留一个系统代理模式。5.3 重放请求失败或响应异常重放请求出现500或者响应为空通常不是越权漏洞而是你的低权限Cookie没有正确传递。可以打开BurpSuite的Proxy页签里的HTTP history找到一条被Autorize重放的请求在Request面板里查看实际发送的Cookie值。还有一点容易被忽略很多应用在登录后会验证Referer头或者Origin头Autorize在重放时虽然会保留原始请求头但如果你在Cookie替换过程中误改了其他字段可能导致请求被应用安全策略拦截。遇到这种情况建议关掉Add Header里的自定义值只保留Cookie替换这一个动作。5.4 误报多、排除脚本类请求Autorize默认会把JS、CSS、图片等静态资源的请求也重放一遍。如果你没有提前在Scope里排除这些路径结果列表里会有大量长度相同、状态码200的记录干扰你识别真正的越权问题。我的习惯是在配置阶段就把.js、.css、.png、.jpg、.gif、.svg、.woff、.ico这些后缀统一排除。使用BurpSuite的Scope配置界面在Exclude from scope里添加这些后缀匹配规则。正则写成\.(js|css|png|jpg|jpeg|gif|svg|woff|ttf|ico)$就行。5.5 高权限账号被强制下线有一种常见情况你刚在高权限账号上操作几下系统就把你踢下线了提示会话失效或异地登录。这是因为你在同一台浏览器里切换了低权限和高权限账号而应用检测到同一个浏览器环境里出现了两个不同会话触发了安全策略。解决办法是使用两个独立的浏览器。比如Chrome登录高权限账号Firefox登录低权限账号。两边通过同一个BurpSuite代理互不干扰。这种方案最稳定也最接近真实用户场景。如果应用对单一浏览器指纹有更严格的要求还可以用Chrome无痕模式窗口开一个独立会话但与另一个正常窗口仍然共享部分指纹信息安全性不如双浏览器方案。6. 实操心得与扩展建议根据自己的项目经验补充一些延展思考。先说一个判断逻辑上的补充。垂直越权测试不能局限于“页面上的请求”。有时候管理员在后台点击“删除用户”前端只发了一个POST /api/user/delete你测了它确实存在越权就完事了吗远远不够。真正危险的越权往往藏在业务流里而不是单个接口。有些系统暴露了完整的RESTful风格接口比如/api/v1/users/{id}这种你把ID从1遍历到1000可能全是高权限接口。Autorize能帮你覆盖“已知路径”的检测但路径发现还得靠你手工或借助其他工具做接口枚举。所以我在做越权测试时通常会先用dirsearch或者BurpSuite的Content discovery功能跑一遍常见路径再把找到的管理路径手动在高权限账号下访问一遍让Autorize进行重放验证。还有一个提升效率的经验配合BurpSuite的Logger插件。Autorize只展示重放请求的对比结果不会记录完整请求头、响应头等详细信息。你可以在测试时开启Logger让它记录所有经过BurpSuite的请求包括Autorize发送的重放请求。这样出现可疑结果时你能快速在Logger里定位到具体请求查看发送的实际Cookie和响应详情比在Autorize页面里翻日志高效很多。另外测试过程中建议每个阶段都做记录。我习惯在Excel里维护一张表列出测试日期、功能模块、接口路径、高权限响应状态、低权限响应状态、响应内容简述、最终结论。后期写测试报告时直接从这个表里提取素材。越权测试的报告重点不是“哪个URL有问题”而是“哪个业务功能点存在权限缺失”配合接口路径和复验截图整个漏洞描述才算完整。最后说一说Autorize的局限性方便你安排测试预期。第一它不能处理需要动态签名的请求。如果应用在请求头里加入了时间戳、nonce或签名参数重放时签名必然失效检测结果基本是失败的。这种情况只能手工测或者通过对签名算法做逆向后再自动化。第二它对于同一接口存在两种权限的情况仅基于响应对比不能判断业务逻辑是否正确。比如一个接口对管理员返回全部数据对普通用户返回部分数据Autorize看到两个200但长度不同只会标记为“可疑”需要人工进一步确认是否存在数据泄露。第三它是一次性检测不代表系统绝对安全。垂直越权漏洞往往和水平越权混合存在建议Autorize测完后再把低权限账号和高权限账号互换反向测一次看看高权限接口是否被低权限身份访问到同时也能发现一些隐藏的水平越权问题。做越权测试这几年我最大的感触是工具永远只是辅助真正的判断力来自对业务逻辑的理解。Autorize帮我把“重复劳动”压缩到了极限但“哪些请求值得测、测得的结果意味着什么”这两个问题始终离不开对系统功能、角色权限模型的深入分析。把这套半自动流程跑熟练之后你会有更多精力用在思考漏洞的本质上而不是耗费在复制粘贴Cookie和重复点发送按钮上。