【SRC】越权漏洞检测

逻辑漏洞学习笔记：越权实战指南

一、 核心概念定义

越权漏洞（Authorization Bypass） 是指应用程序在检查用户权限时存在逻辑缺陷，导致攻击者可以访问或操作本不属于其权限范围内的资源。

根据权限维度的不同，主要分为两类：

• 水平越权（Horizontal Privilege Escalation）：
  • 定义： 攻击者尝试访问与自己拥有相同权限等级的其他用户的资源。
  • 例子： 你是学生A，通过修改参数，操作了学生B的账号。
• 垂直越权（Vertical Privilege Escalation）：
  • 定义： 攻击者利用低权限账号，尝试访问或操作高权限账号（如管理员）的资源。
  • 例子： 普通用户获得了管理员 admin 的权限。

---

二、 常见挖掘思路与检测方法

1. 水平越权挖掘

• 核心逻辑： 寻找能够标识用户身份的参数（如 ID、编号）。
• 实战操作：
  • 观察请求中的参数，例如个人资料 ID 是 123。
  • 尝试直接修改 ID 为 124，查看是否能获取 ID 为 124 用户的敏感信息。
• 重要安全红线：
  • 在进行水平越权测试（特别是 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）或内容，看是否出现非当前账号的敏感信息（姓名、手机号等）。

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 更新了关键索引。
• 测试步骤：
  1. 注册两个账号：账号 A（攻击者）和账号 B（受害者，也可以是管理员）。
  2. 账号 A 登录，发起"修改密码"请求，抓包。
  3. 将包内的 ID 修改为账号 B 的 ID（或将用户名改为 B，视逻辑而定）。
  4. 灾难发生：
     • 系统可能将账号 B 的密码改成了 A 设置的新密码。
     • 或者，系统逻辑错乱，导致 A 和 B 的数据索引冲突。
• 后果： 两个账号都无法正常登录，或数据发生不可逆的错乱。
• 高危场景： 如果攻击者去碰撞管理员账号，会导致管理员无法登录，造成拒绝服务（DoS）攻击。
• 警告 此漏洞极具破坏性，禁止在生产环境对非授权或不可恢复的账号进行测试。测试时务必使用两个自己注册的测试号。

四.企业 SRC 实战笔记

在电商与物流业务中，收货地址接口是越权漏洞的"重灾区"。因为它必然包含用户最敏感的隐私（姓名、电话、住址），且业务逻辑中经常涉及地址的频繁增删改查（CRUD），开发人员极易在某个环节遗漏权限校验。

增加/修改类越权（覆盖与抢占）

这是危害最大的一类，攻击者可以直接篡改他人数据，甚至在他人账号中"埋雷"。

1. 修改/覆盖地址越权

• 原理： 修改地址的接口（update）未校验 address_id 与当前用户的绑定关系。
• 测试步骤：
  1. 账号准备： 注册账号 A（攻击者）和账号 B（受害者）。
  2. 获取 ID： 账号 B 添加一个地址，抓包获取该地址的 address_id（例如：10086）。
  3. 越权操作：
     • 账号 A 修改自己的地址，抓包。
     • 将包内的 address_id 替换为 10086（账号 B 的 ID）。
     • 修改收货人、电话等信息，发送请求。
  4. 验证： 登录账号 B，查看地址 10086 的内容是否变成了账号 A 填写的内容。
  5. 危害： 恶意覆盖他人地址，导致物流配送错误，或恶意骚扰。

2. 特殊案例：长 ID 规律遍历（你提供的案例）

• 场景特征： 系统使用的不是简单的数字 ID，而是看起来像哈希的长字符串 ID，但其中包含可变的部分。

• 实战案例复现：

  • 第一步（发现规律）：

    • 账号 A 添加地址，抓包发现 address_id 为：

      0B1F9EC0B172 9634E063E8F9081425B4

    • 观察发现，中间的 172 看起来像是一个自增序列或特定标识。

  • 第二步（尝试遍历）：

    • 攻击者猜测其他用户的 ID 可能只是中间三位不同。

    • 将 172 修改为 175，构造新的 ID：

      0B1F9EC0B175 9634E063E8F9081425B4

  • 第三步（越权添加/修改）：

    • 使用账号 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。
• 测试步骤：
  1. 账号 A 下单，选择自己的地址 ID AAA。
  2. 账号 B 有一个地址 ID BBB。
  3. 越权操作：
     • 账号 A 点击"提交订单"，抓包。
     • 找到参数 address_id 或 receiver_id。
     • 将 AAA 修改为 BBB（账号 B 的地址 ID）。
  4. 结果：
     • 情况一（越权使用）： 订单生成成功，收货地址显示为账号 B 的地址。这可能导致恶意给他人发货（货到付款诈骗）。
     • 情况二（信息泄露）： 订单详情页虽然显示账号 B 的地址，但接口可能会返回账号 B 的完整地址信息，导致隐私泄露。

---

挖掘技巧

1. 参数名敏感度： 重点关注 addressId、addr_id、delivery_id、receiverId。
2. 接口隐蔽性： 有些 APP 会有"设为默认地址"的接口，这个接口往往校验更松，容易出现越权修改。
3. MD5 并非不可破： 遇到类似 0B1F... 的 ID，先不要放弃，尝试变动账号信息（如重新添加一次）看 ID 是否变化，判断是否为规律性的 Hash。

五. Edu（教育行业）常见逻辑越权

教育行业的系统通常外包给不同的厂商，且历史包袱重，开发人员往往为了省事留下很多逻辑漏洞。

1. "接口联动"攻击链：越权查看 + 越权删除

这是一个利用两个不同接口完成一次完整攻击的高级思路。很多时候单独测一个接口无法证明危害，结合起来就是高危。

• 原理： 开发者在"删除文件"接口中，不是通过 ID 删除，而是通过物理路径删除（懒惰写法）。
• 攻击步骤：
  1. 第一步（获取路径）： 找到"查看文件/图片"的接口。修改参数中的 id（如学号或文件ID），越权查看别人的文件。此时，响应包中通常会返回该文件的完整存储路径 （如 /upload/2026/01/student_123.jpg）。
  2. 第二步（执行删除）： 找到"删除文件"的接口（通常参数名为 path、file_path 或 url）。
  3. 第三步（组合利用）： 将第一步获取到的别人文件的路径，填入到第二步的删除接口中。
  4. 结果： 服务器不校验文件归属，直接根据路径删除了他人文件，造成数据丢失 。

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）。
• 利用链条：
  1. 在 GitHub 源码中发现测试账号。
  2. 回到学校的登录入口（SSO统一认证或后台），使用该账号登录。
  3. 连锁反应： 教育平台通常是统一身份认证 。一旦这个测试账号能登录，往往意味着你可以直接访问 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 (实战必做)

1. 搜 GitHub： 域名 + admin，找源码里的 test 账号。
2. 看响应包： 别信前端页面，盯着 Response 看有没有隐藏的身份证号。
3. 测删除链： 先越权查路径，再把路径填到删除接口里。
4. 改参数为空： 搜不到人？把搜索参数删了或者改成 null 试试，没准出来全校名单。
5. ID 遍历： 找到一个 ID 就丢进 Burp Intruder 跑一遍，看看是不是连号的。