文章总结： 本文详细介绍了作者利用垂直越权漏洞获取770条明文密码的实战案例，指出会话值一致性是关键成因。文章构建了完整的越权漏洞挖掘体系，涵盖漏洞分类、双账号测试心法、七种实战武器如ID遍历与滞空参数、以及Autorize等自动化工具应用。通过组合攻击与真实案例解析，文章强调了业务逻辑理解的重要性，并提供了针对性的防御建议与自查清单，极具实战指导价值。 综合评分： 96 文章分类： 渗透测试,SRC活动,WEB安全,实战经验,漏洞分析
一个越权，我拿到了770条明文密码，厂商只是重启了一下服务器。
原创
梦到什么写什么 梦到什么写什么
逍遥子讲安全
2026年2月16日 01:10 广东
一个越权漏洞，让我在3小时里拿到了770条明文密码，而厂商的修复方式只是“重启了一下服务器”。
去年某次测试，我遇到了一个诡异的垂直越权——时有时无，毫无规律。折腾两小时后发现真相：普通用户和管理员的SESSION值竟然会在一段时间内完全一致。管理员在线时，普通用户直接变身超级管理员；管理员下线，漏洞消失。
这个漏洞让我拿到了770条明文密码，也让厂商紧急修复了他们的SESSION生成逻辑。奖金：6,000元。
越权漏洞在SRC中的出现频率极高，但大多数猎人对它的理解还停留在“改个ID试试”。本文将首次完整公开我的越权漏洞深度狩猎体系——从漏洞分类、挖掘思路、自动化工具到高级利用技巧，全是实战干货。
第一章 重新认知越权：SRC的“高产矿区”
1.1 为什么越权是SRC的必争之地
| 维度 | 数据 | 说明 | | — | — | — | | 出现频率 | OWASP Top 10 2021 第1位 | 访问控制失效是最普遍的Web安全风险 | | 奖金区间 | 500-8000元 | 水平越权中危居多，垂直越权易出高危 | | 挖掘门槛 | 低 | 无需复杂工具，逻辑思维即可 | | 自动化难度 | 高 | 业务逻辑强依赖，纯自动化误报率极高 |
核心认知：越权是业务逻辑漏洞，不是技术漏洞。这意味着：你越懂业务，越能挖到别人挖不到的越权。
1.2 越权的三类形态
| 类型 | 定义 | 典型场景 | 奖金参考 | | — | — | — | — | | 水平越权 | 权限相同的用户之间互相访问 | A用户看到B用户的订单、个人资料 | 500-3000元 | | 垂直越权 | 低权限用户访问高权限功能 | 普通用户执行管理员操作 | 2000-8000元 | | 未授权访问 | 无需登录即可访问需认证接口 | 直接访问后台API、敏感文件 | 800-4000元 |
关键点：三类漏洞经常组合出现——比如通过未授权访问拿到用户ID列表，然后利用水平越权遍历所有用户数据。
第二章 越权挖掘的“核心心法”：一个账号不够，两个起步
2.1 必备的测试环境配置
最低要求：2个不同权限的账号（普通用户A、普通用户B）+ 1个管理员账号（如有）
推荐配置：
- Chrome + Firefox（或Chrome普通模式+无痕模式）分别登录不同账号
- Burp Suite配置好，分别捕获两个账号的流量
- 准备一个用于接收数据的Collaborator或测试服务器
2.2 越权测试的标准流程
1. 登录高权限账号（或A账号） → 正常操作目标功能 → 捕获请求2. 将请求发送到Repeater3. 替换身份凭证为低权限账号（或B账号）的凭证4. 发送请求，对比响应5. 如果能获取到同样数据，则存在越权
核心原则：一切参数皆可篡改——不仅是URL里的id，还有POST body、Cookie、Header、Referer、Origin，甚至HTTP方法。
第三章 实战挖掘的“七种武器”
3.1 数字型ID越权：最基础，也最容易漏
场景：用户信息接口 /user/profile?id=1001
测试方法：
- 登录A账号，获取自己的id=1001
- 替换为B账号的id=1002，查看是否能获取B的信息
- 编写脚本遍历id范围（1001-2000）
实战案例：某站仪表盘编辑标签处存在mainId参数，修改后可获取其他用户的文章信息。
3.2 UUID/不可遍历ID越权：看起来难，其实有3种破法
场景：用户id为 user_8f3d2a7e9c1b4k5m 这种无规律字符串
破法1：利用可遍历ID的接口获取不可遍历ID
某平台用户id不可遍历，但群组id可遍历。通过遍历gourpId获取群组成员列表，从中拿到所有用户的不可遍历id，再用这些id去越权访问用户隐私数据。
破法2：利用接口报错泄露
发送错误格式的不可遍历id，接口返回“找不到用户，可用的id有：xxx”。某次测试中，一个报错直接返回了全部1000+用户的id列表。
破法3：不可遍历ID可能是公开的
某平台文件编辑功能需要fileId（不可遍历），但分享文件时，URL中直接暴露了这个id。这意味着：任何能访问该分享链接的人，都可以通过越权编辑/删除该文件。
3.3 路径中的越权：不止是参数
场景：RESTful风格的API，id直接放在路径里
PATCH /api/okr/516668/updateGET /api/task/87321/detail
测试方法：直接修改路径中的数字
实战案例：某OKR平台，A账号修改OKR时抓包，发现路径中516668为OKR ID。修改此ID为B账号的OKR ID，成功越权修改他人OKR内容。
3.4 JSON数组越权：一个请求打一片
场景：选择多个用户发送通知，请求格式为：
json{"users": [89045]}
测试方法：手动添加多个id
{"users": [89045, 89046, 89047, 89048...]}
实战效果：返回包中泄露了所有被添加用户的信息，且由于id可遍历，可以一次性获取全站用户数据。
3.5 滞空参数越权：删掉限制，还你全部
场景：请求中包含某些身份标识参数
测试方法：尝试删除这些参数，或置空
实战案例：某小程序地址管理接口，请求头中包含 memberxxx 和 openxxx 两个参数。将这两个参数值置空后，接口返回了所有用户的收货地址。
3.6 Cookie/Session值一致导致的特殊越权
这是我遇到过最精彩的案例
现象：垂直越权时有时无，管理员在线时能越权，管理员下线后不能。
原因：对比后发现，普通用户和管理员的SESSION值竟然完全一致。短时间内系统给不同权限用户生成了相同的SESSION。
利用：只要管理员在线，普通用户直接变身超级管理员，可以调用所有管理员接口。最终从 /user/getUserList?role=0 接口获取了770多条用户数据，其中93%的密码是弱口令123456。
3.7 修改响应状态码的“骚操作”
场景：登录验证时，前端根据返回的status判断是否成功
测试方法：将错误的status（如2）改为正确的（如1），可能绕过登录
原理：某些开发偷懒，后端只验证参数是否传了，不验证值的正确性。
第四章 自动化工具：把重复劳动交给机器
4.1 越权检测的自动化难点
核心问题：误报率极高。因为很多公共页面（如首页、公告）所有用户都能访问，替换token后响应一致不代表越权。
传统方案误报率：高达99%
4.2 Autorize/AutorizePro：半自动化神器
Autorize：经典的Burp越权检测插件，原理是自动替换请求中的Cookie/Header，对比响应。
AutorizePro：增强版，加入AI分析模块，将误报率从99%降至5%。
使用技巧：
- 配置好高权限用户的Cookie/Token
- 启用插件，正常浏览应用
- 插件自动对每个请求进行“低权限用户”版本测试
- 重点关注“Bypassed”状态的请求
4.3 自研越权检测插件的思路
Freebuf上有开发者分享了越权插件开发实战，核心思路是：
- 根据设置的资源ID和返回包的敏感信息，自动筛选高风险接口
- 自动收集配置域名的所有参数
- 通过被动扫描的方式对接口进行检测
关键筛选条件：
- URL中包含可遍历的资源ID（如id、uid、orderId）
- 返回包中包含敏感信息（如手机号、身份证、真实姓名）
第五章 高级技巧：把越权打出“组合拳”
5.1 不可遍历ID的危害扩大术
技巧1：通过可遍历ID获取不可遍历ID
某平台用户id不可遍历，但群组id可遍历。流程：
遍历gourpId=1-1000 → 获取每个群的成员列表 → 拿到所有用户的不可遍历id → 用这些id越权访问用户隐私
技巧2：利用分享功能暴露不可遍历ID
文件分享时，URL中直接暴露了fileId。这意味着：任何能看到分享链接的人，都可以越权操作该文件（编辑、删除、查看）。
5.2 组合多个越权构建攻击链
案例：某平台有两处漏洞
- 漏洞A：未授权访问泄露用户id列表（含手机号）
- 漏洞B：修改密码接口存在水平越权
攻击链：未授权访问拿到目标用户的id → 用B接口修改目标用户密码 → 登录该用户 → 获取更多权限
5.3 从越权到数据泄露的最后一公里
拿到用户id列表后，如何快速提取数据？
批量请求脚本（Python）：
import requestsimport threadingurl = "https://target.com/api/user/profile"cookies = {"session": "your_session"}def fetch_user(uid): params = {"id": uid} r = requests.get(url, params=params, cookies=cookies) if r.status_code == 200: print(f"UID {uid}: {r.text[:100]}")# 多线程遍历for uid in range(1001, 2000): t = threading.Thread(target=fetch_user, args=(uid,)) t.start()
第六章 实战案例库
【案例1】谷歌论坛GWT应用的越权
来源：Google Groups漏洞，奖金500美元
背景：Google论坛使用GWT（Google Web Toolkit）构建，请求看起来像乱码。
挖掘过程：
- 分析GWT请求结构，发现数字代表特定类
- 用Burp爆破出所有类名
- 创建两个测试组，一个设为private
- 用第一个账号请求第二个private组的信息，成功获取到组邮件和描述
漏洞价值：即使权限设置为private，非组成员也能看到敏感信息。
【案例2】SESSION值一致导致的垂直越权
来源：某安全团队投稿
目标：某企业后台系统
挖掘过程：
- 登录管理员，调用
/user/getUserList?role=0获取用户列表 - 复制请求，替换为普通用户的SESSION，发现也能访问（当时管理员在线）
- 第二天重新测试，发现无法越权（管理员已下线）
- 对比两个SESSION，发现完全一致！
- 原理：短时间内普通用户和管理员凭证一致
成果：获取770多条用户数据，含明文密码，93%为弱口令123456。
【案例3】不可遍历ID的三层突破
来源：腾讯云开发者社区
目标：某企业协作平台
漏洞1：编辑标签处mainId可遍历，获取其他用户文章
漏洞2：adminUserIdList可添加任意用户到自己的企业，但用户id不可遍历
突破：
- 通过漏洞1遍历group接口，获取用户id列表
- 用获取的不可遍历id进行adminUserIdList注入
- 成功将目标用户加入自己的企业
- 刷新后获取全站用户数据
启示：两个中危组合，往往等于一个高危。
【案例4】JumpServer的令牌越权（CVE-2025-62712）
来源：开源堡垒机JumpServer
漏洞描述：在v3.10.20-lts及v4.10.11-lts之前的版本中，经过身份验证的非特权用户可以通过 /api/v1/authentication/super-connection-token/ 端点检索到其他用户的连接令牌。
影响：攻击者可代表原始令牌所有者连接到管理的资产，导致敏感系统未经授权访问。
CVSS评分：9.6（严重）
教训：越权漏洞不仅存在于Web应用，堡垒机、运维系统同样高危。
第七章 防御视角：为什么你的系统总在“越权”
7.1 开发者最常犯的5个错误
- 从客户端获取用户标识：
user_id从POST/GET取，而非SESSION - 只验证“是否登录”，不验证“谁登录”
- 生成SESSION时未保证唯一性：导致不同用户SESSION相同
- 忽略默认权限：新功能上线时默认所有人可访问
- 响应状态码可篡改：前端根据
status=1判断成功
7.2 企业自查清单
- 所有敏感接口是否验证了当前用户与操作对象的从属关系？
- 是否使用了统一的权限验证中间件，而非在各个接口中单独实现？
- 是否存在通过修改HTTP方法（GET→POST）绕过权限的情况？
- SESSION生成机制是否保证唯一性和随机性？
- 是否有自动化工具定期扫描越权漏洞？
第八章 结语：越权的本质是“信任”
越权漏洞之所以如此普遍，根本原因在于：开发人员默认用户不会篡改参数。
他们信任客户端传来的id、信任Cookie里存的user_role、信任每一个请求都是合法的。但作为攻击者，我们的工作就是打破这种信任。
下次测试时，记住一句话：
任何由客户端传入的、用于标识用户身份或权限的参数，都是越权的潜在爆发点。
参数在哪儿，越权就在哪儿。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：逍遥子讲安全 梦到什么写什么 梦到什么写什么《一个越权，我拿到了770条明文密码，厂商只是重启了一下服务器。》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论