【SRC】越权漏洞检测
逻辑漏洞学习笔记：越权实战指南
一、 核心概念定义
越权漏洞（Authorization Bypass） 是指应用程序在检查用户权限时存在逻辑缺陷，导致攻击者可以访问或操作本不属于其权限范围内的资源。
根据权限维度的不同，主要分为两类：
- 水平越权（Horizontal Privilege Escalation）：
- 定义： 攻击者尝试访问与自己拥有相同权限等级的其他用户的资源。
- 例子： 你是学生A，通过修改参数，操作了学生B的账号。
- 垂直越权（Vertical Privilege Escalation）：
- 定义： 攻击者利用低权限账号，尝试访问或操作高权限账号（如管理员）的资源。
- 例子： 普通用户获得了管理员 admin 的权限。
二、 常见挖掘思路与检测方法
1. 水平越权挖掘
- 核心逻辑： 寻找能够标识用户身份的参数（如 ID、编号）。
- 实战操作：
- 观察请求中的参数，例如个人资料 ID 是
123。 - 尝试直接修改 ID 为
124，查看是否能获取 ID 为 124 用户的敏感信息。
- 观察请求中的参数，例如个人资料 ID 是
- 重要安全红线：
- 在进行水平越权测试（特别是 SRC 挖掘）时，必须自己注册两个账号进行互测（账号 A 越权操作账号 B）。
- 严禁越权操作其他真实用户的正常账号，这是违规且违法的行为。
2. 垂直越权挖掘
主要有三种常见的检测手法：
- 方法一：高权低用（替换 Cookie）
- 准备两个账号：账号 A（高权限/管理员）、账号 B（低权限）。
- 使用账号 A 访问高权限功能，并抓包。
- 将数据包中的 Cookie 替换为低权限账号 B 的 Cookie。
- 判断： 如果替换后仍能成功执行高权限操作，则存在垂直越权。
- 方法二：参数篡改（身份标识欺骗）
- 只有一个低权限账号时，检查请求包中是否有标识权限等级的参数（如
admin=0、role=user）。 - 尝试修改参数，例如将
admin=0改为admin=1，看是否能提权。
- 只有一个低权限账号时，检查请求包中是否有标识权限等级的参数（如
- 方法三：强制浏览（未授权访问）
- 收集高权限功能的 URL 路径或接口。
- 使用低权限账号登录（或不登录），直接访问这些高权限 URL，测试服务端是否鉴权。
三、实战测试技巧
1. 凭证替换测试（垂直越权核心验证）
在入职后的正规项目测试中，通常要求客户提供两个不同权限的账号（高权限 Admin + 低权限 User）。
- 测试手法：
- 登录低权限账号，抓包获取其
Token、Authorization或Cookie。 - 登录高权限账号，找到只有管理员才能操作的功能接口（如“添加用户”）。
- 抓包该高权限请求，将其中的高权限凭证替换为低权限账号的凭证。
- 登录低权限账号，抓包获取其
- 目的： 验证服务端是只认“接口”还是认“人”。如果替换后请求成功，证明低权限用户也可以调用高权限功能。
2. ID 遍历与爆破（水平越权危害放大）
- 测试手法： 发现某个接口（如订单查询、用户信息）存在越权后，不要只测一个 ID。
- 工具利用： 发送到 Burp Suite 的 Intruder 模块。
- 目的： 设置 Payload 进行批量 ID 爆破。如果能批量返回不同用户的敏感数据，漏洞危害等级将直接从“普通越权”提升为“大量敏感信息泄露（高危）”。
3. 数据覆盖与删除（消息/资源操作）
- 场景： 针对消息修改、文章编辑、资源删除等功能。
- 前置条件： 必须自己注册两个账号（账号 A 和 账号 B）。
- 测试手法：
- 账号 A 发起修改自己消息的请求，抓包。
- 将包内的
message_id修改为账号 B 的message_id。
- 结果： 如果账号 B 的消息被覆盖、修改或删除，即证明存在越权操作漏洞。
4. URL 路径越权（中危 - 个人信息）
- 特征： 越权参数不在 Body 或 Query 参数中，而是直接存在于 URL 路径里。
- 案例： 点击查看个人信息，URL 显示为
domain.com/user/1234567/。 - 测试手法：
- 直接对 URL 末尾的数字进行爆破（如从
1234500扫到1234600）。 - 判断： 观察返回包的大小（Length）或内容，看是否出现非当前账号的敏感信息（姓名、手机号等）。
- 直接对 URL 末尾的数字进行爆破（如从
5. 接口泄露组合拳（无规律 ID 突破）
- 难点： 目标接口（如商品评论、排行榜）存在越权可能，但
userid是加密的哈希值（如u-a1b2c3d4），无法直接遍历。 - 突破口： 寻找辅助接口。
- 测试手法：
- 全站寻找其他接口（如
/userlist、/search、/get_comments）。 - 如果在这些辅助接口的返回包中泄露了其他人的
userid（哈希值）。 - 组合攻击： 将获取到的他人 Hash ID，填入到有漏洞的接口中，完成越权。
- 全站寻找其他接口（如
6. 长 ID 部分爆破策略
- 场景： 遇到特别长的 ID（如 UUID 或长整型），完全随机爆破不可能成功。
- 测试手法：
- 注册两个账号，观察 ID 规律。
- 找规律： 发现前半部分（如时间戳、区域码）是一样的，只有后 4-6 位不同。
- 攻击： 保持前半部分不变，仅对后半部分差异位进行 Burp 爆破。
7.账号碰撞与销毁（逻辑 DoS）
这是一种特殊的逻辑缺陷，通常发生在账号体系设计混乱的系统中。
- 原理： 数据库或后端逻辑在处理“修改密码”或“账号更新”时，未校验 Session 身份与目标 ID 的一致性，且直接根据 ID 更新了关键索引。
- 测试步骤：
- 注册两个账号：账号 A（攻击者）和账号 B（受害者，也可以是管理员）。
- 账号 A 登录，发起“修改密码”请求，抓包。
- 将包内的 ID 修改为账号 B 的 ID（或将用户名改为 B，视逻辑而定）。
- 灾难发生：
- 系统可能将账号 B 的密码改成了 A 设置的新密码。
- 或者，系统逻辑错乱，导致 A 和 B 的数据索引冲突。
- 后果： 两个账号都无法正常登录，或数据发生不可逆的错乱。
- 高危场景： 如果攻击者去碰撞管理员账号，会导致管理员无法登录，造成拒绝服务（DoS）攻击。
- 警告 此漏洞极具破坏性，禁止在生产环境对非授权或不可恢复的账号进行测试。测试时务必使用两个自己注册的测试号。
四.企业 SRC 实战笔记
在电商与物流业务中，收货地址接口是越权漏洞的“重灾区”。因为它必然包含用户最敏感的隐私（姓名、电话、住址），且业务逻辑中经常涉及地址的频繁增删改查（CRUD），开发人员极易在某个环节遗漏权限校验。
增加/修改类越权（覆盖与抢占）
这是危害最大的一类，攻击者可以直接篡改他人数据，甚至在他人账号中“埋雷”。
1. 修改/覆盖地址越权
- 原理： 修改地址的接口（
update）未校验address_id与当前用户的绑定关系。 - 测试步骤：
- 账号准备： 注册账号 A（攻击者）和账号 B（受害者）。
- 获取 ID： 账号 B 添加一个地址，抓包获取该地址的
address_id（例如：10086）。 - 越权操作：
- 账号 A 修改自己的地址，抓包。
- 将包内的
address_id替换为10086（账号 B 的 ID）。 - 修改收货人、电话等信息，发送请求。
- 验证： 登录账号 B，查看地址
10086的内容是否变成了账号 A 填写的内容。 - 危害： 恶意覆盖他人地址，导致物流配送错误，或恶意骚扰。
2. 特殊案例：长 ID 规律遍历（你提供的案例）
-
场景特征： 系统使用的不是简单的数字 ID，而是看起来像哈希的长字符串 ID，但其中包含可变的部分。
-
实战案例复现：
-
第一步（发现规律）：
-
账号 A 添加地址，抓包发现
address_id为：0B1F9EC0B1729634E063E8F9081425B4 -
观察发现，中间的
172看起来像是一个自增序列或特定标识。
-
-
第二步（尝试遍历）：
-
攻击者猜测其他用户的 ID 可能只是中间三位不同。
-
将
172修改为175，构造新的 ID：0B1F9EC0B1759634E063E8F9081425B4
-
-
第三步（越权添加/修改）：
- 使用账号 A 发送修改请求，目标 ID 填入构造好的“175 ID”。
-
第四步（验证危害）：
- 登录账号 B（假设其对应 175），发现账号下多出了一个陌生地址，或者原有的地址被修改了。
-
-
技术总结： 即使是长 ID，也不代表安全。尝试注册两个连续的账号，Diff（对比） 两个 ID 的差异，往往能发现“伪加密”的规律（如时间戳+递增ID+固定盐值）。
3. 增加地址越权（ID 抢占/关联错误）
- 原理： 在添加地址时，请求包中如果包含
user_id参数，修改该参数可能导致将地址“加”到别人名下。 - 测试手法： 账号 A 添加地址，抓包将
user_id改为账号 B 的 ID。如果成功，账号 B 的地址列表中会多出一条攻击者填写的地址。
删除类越权（数据破坏）
1. 单个删除越权
- 测试手法：
- 账号 A 点击删除自己地址，抓包。
- 将
address_id替换为账号 B 的地址 ID。 - 结果： 账号 B 的地址凭空消失。
2. 批量删除越权（高危）
- 特征： 接口参数名为
ids[]、id_list或逗号分隔的字符串101,102。 - 测试手法：
- 抓包批量删除接口。
- 构造 Payload：
ids=[账号B_ID_1, 账号B_ID_2, ...]。 - 危害： 一次请求清空受害者的地址簿，造成严重的业务干扰（DoS）。
查看类越权（隐私泄露）
1. 详情查看越权
- 测试手法：
- 找到“编辑地址”或“查看详情”的按钮。
- 抓包
GET /api/address/detail?id=123。 - 遍历 ID（如
123->124）。 - 危害： 响应包中直接返回他人的姓名、手机号、详细门牌号。这是企业 SRC 中最典型的P1/P2 级漏洞。
2. URL 路径越权
- 特征： ID 不在参数里，而在 URL 路径中，如
/api/v1/user/1001/address。 - 测试手法： 修改路径中的
1001为1002，直接访问，看是否返回 JSON 数据。
业务流程越权（下单逻辑绕过）
这是最隐蔽、也最容易被忽略的场景。
下单时引用他人地址
- 场景： 在“确认订单”页面，用户需要选择一个收货地址 ID。
- 测试步骤：
- 账号 A 下单，选择自己的地址 ID
AAA。 - 账号 B 有一个地址 ID
BBB。 - 越权操作：
- 账号 A 点击“提交订单”，抓包。
- 找到参数
address_id或receiver_id。 - 将
AAA修改为BBB（账号 B 的地址 ID）。
- 结果：
- 情况一（越权使用）： 订单生成成功，收货地址显示为账号 B 的地址。这可能导致恶意给他人发货（货到付款诈骗）。
- 情况二（信息泄露）： 订单详情页虽然显示账号 B 的地址，但接口可能会返回账号 B 的完整地址信息，导致隐私泄露。
- 账号 A 下单，选择自己的地址 ID
挖掘技巧
- 参数名敏感度： 重点关注
addressId、addr_id、delivery_id、receiverId。 - 接口隐蔽性： 有些 APP 会有“设为默认地址”的接口，这个接口往往校验更松，容易出现越权修改。
- MD5 并非不可破： 遇到类似
0B1F...的 ID，先不要放弃，尝试变动账号信息（如重新添加一次）看 ID 是否变化，判断是否为规律性的 Hash。
五. Edu（教育行业）常见逻辑越权
教育行业的系统通常外包给不同的厂商，且历史包袱重，开发人员往往为了省事留下很多逻辑漏洞。
1. “接口联动”攻击链：越权查看 + 越权删除
这是一个利用两个不同接口完成一次完整攻击的高级思路。很多时候单独测一个接口无法证明危害，结合起来就是高危。
- 原理： 开发者在“删除文件”接口中，不是通过 ID 删除，而是通过物理路径删除（懒惰写法）。
- 攻击步骤：
- 第一步（获取路径）： 找到“查看文件/图片”的接口。修改参数中的
id（如学号或文件ID），越权查看别人的文件。此时，响应包中通常会返回该文件的完整存储路径（如/upload/2026/01/student_123.jpg）。 - 第二步（执行删除）： 找到“删除文件”的接口（通常参数名为
path、file_path或url）。 - 第三步（组合利用）： 将第一步获取到的别人文件的路径，填入到第二步的删除接口中。
- 结果： 服务器不校验文件归属，直接根据路径删除了他人文件，造成数据丢失 。
- 第一步（获取路径）： 找到“查看文件/图片”的接口。修改参数中的
2. “前端掩盖”式敏感信息泄露
- 原理（懒惰行为）： 后端SQL查询时图省事用了
SELECT *把用户的所有信息（身份证、家庭住址、密码Hash、手机号）全部查出来了，但在前端页面通过 JS 只展示了“姓名”和“学号”几项 。 - 实战操作：
- 在“个人信息查询”、“用户搜索”或“通讯录”处抓包。
- 不要只看页面！ 重点查看 Burp Suite 中的 Response（响应包）。
- 你会发现响应包的大小（Length）异常大，里面躺着几十条页面上没显示的敏感数据 。
- 进阶： 结合 ID 遍历，批量抓取响应包，即可通过脚本“拖库”全校学生隐私。
3. 默认密码 + ID 遍历 = 批量任意登录
- 背景： 学校系统往往有默认密码规则（如
123456、身份证后六位、NewUser@123）。 - 难点： 你知道默认密码，但不知道别人的账号（学号/工号）。
- 突破口（信息泄露接口）：
- 寻找系统中的“选择用户”、“发送消息”、“部门人员列表”等功能。
- 抓包这些接口，往往能返回大量的
user_id、username（学号）。
- 利用： 收集到的 ID列表 + 默认密码 = 批量接管任意账号。登录后可能发现该账号有管理员权限，直接拿下系统 。
GitHub 捡漏逻辑：从源码到内网漫游
1. 搜索逻辑
- 关键词组合： 目标学校域名（如
xxx.edu.cn） + 系统特征词（如admin、system、manage）。 - 目标对象： 寻找被开发人员或学生上传到 GitHub 的项目源码（Source Code）。
2. 核心价值：测试账号
- 漏洞原理： 开发者在写代码时，为了方便调试，经常会在源码的注释、配置文件或数据库初始化脚本中，硬编码写死一个测试账号和密码（如
test/123456或admin/admin888）。 - 利用链条：
- 在 GitHub 源码中发现测试账号。
- 回到学校的登录入口（SSO统一认证或后台），使用该账号登录。
- 连锁反应： 教育平台通常是统一身份认证。一旦这个测试账号能登录，往往意味着你可以直接访问 VPN、教务系统、图书馆系统等全校 90% 的子系统，直接实现内网漫游 。
参数置空技巧：逻辑崩坏
这是一种“盲打”技巧，专门针对后端代码逻辑不严谨的情况。
1. 攻击原理
开发者在写 SQL 拼接或条件判断时，可能写了类似这样的逻辑：
IF (name != null) { SELECT * FROM users WHERE name = $name }ELSE { SELECT * FROM users }(如果没有传名字，就默认显示所有用户)
2. 实战 Payloads
在查询接口（如搜索学生、查看成绩），尝试将关键参数（如 name、id、keyword）的值修改为以下几种情况进行 Fuzz：
- 完全置空：
id=(参数名保留，值为空) - Null 值：
id=null - 通配符：
id=*或name=% - 布尔值：
id=1或id=0 - 特殊字符：
id=undefined
3. 危害表现
- 全量泄露： 系统逻辑判断失效，直接返回数据库中的所有数据（如一下子返回 20,000 条学生信息），导致严重的逻辑越权和信息泄露 。
- 报错泄露： 有时会触发数据库报错，泄露 SQL 语句结构，为 SQL 注入提供线索。
总结 Checklist (实战必做)
- 搜 GitHub： 域名 + admin，找源码里的
test账号。 - 看响应包： 别信前端页面，盯着 Response 看有没有隐藏的身份证号。
- 测删除链： 先越权查路径，再把路径填到删除接口里。
- 改参数为空： 搜不到人？把搜索参数删了或者改成
null试试，没准出来全校名单。 - ID 遍历： 找到一个 ID 就丢进 Burp Intruder 跑一遍，看看是不是连号的。
