当前位置：首页 > news >正文

越权漏洞实战挖掘：从原理到案例，掌握水平与垂直越权防御

news 2026/6/25 21:12:51

1. 项目概述：从“越权”到“精通”的实战之路

在安全测试和渗透测试的日常工作中，越权漏洞（Broken Access Control）绝对是一个高频且极具价值的“猎物”。它不像SQL注入那样需要复杂的语法构造，也不像XSS那样依赖精巧的载荷，很多时候，它更像是一个逻辑上的“后门”，一旦被发现，往往能直通核心数据或功能。这个项目标题——“几个常见的越权漏洞挖掘案例，从零基础到精通，收藏这篇就够了！”——精准地戳中了安全从业者，尤其是初学者的痛点：渴望通过具体、可复现的案例，快速掌握一种漏洞的挖掘思路和实战技巧。

我自己在带新人或者做内部培训时，也深有体会。很多朋友看了很多理论，知道越权分为水平越权和垂直越权，但一到实际环境，面对一个真实的Web应用，却不知从何下手。这篇文章，我就想抛开那些教科书式的定义，直接带你钻进几个我亲手挖过或者复现过的经典案例里。我们会从最基础的“改个ID”开始，一步步深入到需要结合业务逻辑、参数污染甚至时间竞争的复杂场景。我的目标很简单：让你读完这篇文章后，不仅能看懂这些案例，更能建立起一套属于自己的、可迁移的越权漏洞挖掘思维模型。无论你是刚入门的安全爱好者，还是想查漏补缺的开发者，这篇文章里总结的“套路”和踩过的“坑”，都值得你仔细琢磨。

2. 越权漏洞核心原理与分类精讲

在深入案例之前，我们必须把地基打牢。越权漏洞的本质，是应用程序在对用户访问某个资源或执行某个操作进行授权验证时，出现了逻辑缺陷，导致用户能够执行其本不被允许的操作。这个“验证”可能发生在后端代码的权限判断语句里，也可能隐藏在前端参数、Cookie、甚至是请求的顺序中。

2.1 水平越权：同级别用户的“串门”事故

水平越权（Horizontal Privilege Escalation）是最常见的一种。它指的是攻击者能够访问或操作与其拥有相同权限级别的其他用户的资源。举个例子，用户A和用户B都是普通会员，理论上A只能看自己的订单，B只能看自己的订单。但如果存在水平越权，A通过某种方式（比如修改请求中的用户ID参数），就能看到B的订单详情。

核心攻击点：任何用于标识用户唯一身份或资源的参数。最常见的就是数字ID，如user_id=123、order_id=456。此外，用户名、邮箱、手机号，甚至是文件路径（如/download?file=userA_contract.pdf）都可能成为目标。

后端漏洞的典型场景：后端代码接收了前端传来的用户标识（如从JWT token或session中解析出当前用户是A），但在执行“查询用户B的订单”这个操作前，没有再次校验“当前用户A是否有权查询B的订单”。代码可能直接执行了SELECT * FROM orders WHERE order_id = ${input_order_id}，而完全忽略了user_id的关联校验。这就是一个赤裸裸的水平越权。

2.2 垂直越权：普通用户的“僭越”之梦

垂直越权（Vertical Privilege Escalation）的危害性通常更大。它指的是低权限用户能够执行高权限用户才能执行的操作。例如，一个普通论坛用户，通过某种方式能够访问到管理员的后台功能页面，或者调用只有管理员才能使用的API接口，比如删除其他用户的帖子、修改系统配置。

核心攻击点：功能入口、权限标识参数、角色参数。比如，一个“添加管理员”的接口，正常情况下前端根本不会对普通用户展示这个功能的按钮。但攻击者可以通过爬虫、目录扫描或者分析JS代码，直接找到这个接口的路径/admin/addUser。如果后端仅仅依靠“用户是否登录”来判断，而没有校验“用户角色是否为管理员”，那么垂直越权就发生了。

一个常见的混淆点：很多人认为垂直越权一定要看到管理员界面。其实不然。有时，一个普通的“修改个人资料”功能，如果后端没有对可修改的字段做严格限制，攻击者通过修改请求参数，给自己添加一个role=admin的字段，并且后端真的将这个值更新到了数据库，这也是一次成功的垂直越权攻击（权限提升）。

2.3 不安全的直接对象引用与业务逻辑越权

OWASP TOP 10 中常提到的“不安全的直接对象引用”（IDOR）是导致越权的主要原因之一，它更多是水平越权的具体实现方式。而“业务逻辑越权”则是一个更宽泛的概念，它可能不依赖于修改某个ID，而是利用业务流程上的缺陷。

例如，在一个“申诉重置密码”流程中：

用户输入邮箱，系统发送一封含有临时token的邮件。
用户点击邮件链接，进入重置密码页面（URL中带有token）。
漏洞在于：进入重置页面后，后端只验证token有效，但未将token与待重置的账号邮箱进行二次绑定。攻击者可以先用自己的邮箱获取一个合法token，然后在重置页面，将请求中的“新密码”和“确认密码”参数保持不变，但偷偷修改“邮箱”参数为受害者的邮箱。如果后端仅凭token就允许重置，那么攻击者就利用业务流程漏洞，越权重置了他人密码。

这类漏洞的挖掘，需要测试者对应用的业务流程有深入的理解，思考“每一步的验证是否充分”、“状态是否可被恶意绕过”。

注意：越权漏洞的修复，核心原则是“服务端强制授权”。永远不要信任前端传来的任何关于权限和身份的信息（包括隐藏域、Cookie、Header）。每次处理敏感操作或请求敏感数据时，后端都必须根据当前已认证的用户会话（Session/JWT payload），去数据库或缓存中重新查询并确认其是否有权进行此操作。

3. 案例一：骑士CMS靶场 - 经典水平越权漏洞复现与分析

骑士CMS（Knight CMS）是一个经典的PHP内容管理系统，其历史版本中存在的水平越权漏洞是安全入门练手的绝佳材料。我们通过这个案例，来具体拆解一次完整的漏洞挖掘过程。

3.1 环境搭建与目标定位

首先，你需要一个测试环境。可以在虚拟机中安装PHPStudy等集成环境，然后下载骑士CMS的历史漏洞版本（例如某个已知存在漏洞的旧版本）。安装完成后，我们重点关注“会员中心”功能。通常，用户登录后，可以查看和编辑自己的个人信息。

我们的攻击目标是：用户A越权查看或修改用户B的个人资料。常见的入口是“修改资料”页面，其URL可能类似于/member/index.php?m=member&c=index&a=edit。

3.2 漏洞挖掘过程：参数操纵与响应分析

正常操作观察：用两个测试账号（userA和userB）分别登录。登录userA后，进入资料修改页面。使用Burp Suite或浏览器开发者工具抓包，观察提交修改资料的HTTP请求（通常是POST请求）。
寻找关键参数：在请求中，我们很可能发现一个名为userid、id或uid的参数，其值是一个数字，比如userid=5（假设这是userA的用户ID）。同时，表单中还会有username、email等字段。
发起越权测试：保持Burp Suite的拦截功能开启（或使用Repeater模块），在userA的会话下，将POST请求中的userid参数值修改为userB的ID（比如userid=6），而其他字段如username修改为一个新的值（如userA_hacked）。然后转发这个被篡改的请求。
结果验证：
- 场景一（查看越权）：如果请求是获取资料（GET），修改userid后，响应返回了userB的资料信息，则存在信息查看水平越权。
- 场景二（修改越权）：如果请求是更新资料（POST），修改userid和username后，服务器返回“更新成功”。随后，我们退出userA，登录userB，发现userB的用户名果然被改成了userA_hacked。这就证实了存在数据修改水平越权，危害极大。

3.3 漏洞代码根源分析

问题出在后端PHP处理代码上。我们来看一段高度简化的漏洞代码模拟：

// member/edit.php (漏洞版本) $userid = $_POST['userid']; // 直接从用户输入获取目标用户ID $new_username = $_POST['username']; // 假设当前登录用户的ID从session中获取 $current_uid = $_SESSION['user_id']; // 致命的缺失：这里没有检查 $userid 是否等于 $current_uid！ // 正确的逻辑应该加上：if ($userid != $current_uid) { die('无权操作'); } $sql = "UPDATE `user_table` SET `username`='$new_username' WHERE `id`=$userid"; $result = mysql_query($sql); if ($result) { echo "资料更新成功！"; }

这段代码盲目信任了$_POST['userid']，没有将其与当前登录用户的身份（$_SESSION['user_id']）进行比对。这就是“不安全的直接对象引用”的典型例子。

3.4 挖掘技巧与注意事项

不要只测数字ID：除了userid，还要测试所有可能标识对象的参数，如orderid、messageid、fileid，甚至是username、email这种非数字参数。尝试将username=userA改为username=admin。
注意POST和GET：越权可能发生在任何HTTP方法中。对于查看类操作，多测试GET请求的参数；对于更新、删除操作，多测试POST/PUT/DELETE请求的参数。
使用工具提高效率：Burp Suite的 Intruder 模块可以用于自动化爆破ID范围。你可以设置userid参数为 payload，快速遍历一个数字区间（如1-100），观察哪些ID返回了数据（状态码200且有内容），哪些返回了错误（403或空数据）。
留意响应差异：有时服务器不会直接返回目标数据，但响应长度、状态码或错误信息会因ID是否有效而不同。通过对比这些差异，可以判断ID是否有效，从而间接发现越权信息泄露。

实操心得：在测试水平越权时，我习惯先创建一个“靶子”。比如，先用userB账号创建一个便签、订单或上传一个文件，记下其唯一ID（如note_id=100）。然后，在userA的会话中，直接尝试访问/note/view?id=100。这种针对已知目标资源的测试，成功率往往比盲目爆破更高。

4. 案例二：基于功能路径的垂直越权探测

垂直越权的挖掘，往往需要一点“好奇心”和“地图”。我们不再满足于修改参数，而是要去寻找那些本不该出现在我们视线里的“隐藏房间”。

4.1 功能路径的发现与枚举

爬虫与目录扫描：使用工具如gobuster、dirsearch或 Burp Suite 的Content Discovery功能，对目标网站进行目录和文件扫描。寻找像/admin/、/manage/、/backend/、/console/这样的敏感目录。关键词列表可以加入admin、manage、config、upload、dashboard、api等。
前端代码分析：有些管理功能的入口在前端代码（JavaScript）中是存在的，只是通过权限判断隐藏了UI。在浏览器开发者工具的“源代码”（Sources）或“网络”（Network）面板中，仔细搜索admin、role、delete、editAll等关键词，可能会发现被注释掉或动态加载的API接口路径。
参考错误信息与机器人协议：有时访问一个不存在的管理页面会暴露真实路径。也可以查看robots.txt文件，有些开发者会不小心在这里列出管理后台的路径。

4.2 漏洞利用：绕过前端渲染与接口调用

假设我们通过扫描发现了/admin/userList.php这个路径，它显然是一个列出所有用户的管理员功能。

直接访问测试：在普通用户登录的状态下，直接在浏览器地址栏输入https://target.com/admin/userList.php并访问。
观察响应：
- 情况A（直接访问成功）：页面正常加载，显示了所有用户列表。这是最严重的垂直越权，说明该页面零权限校验。
- 情况B（跳转或提示）：页面可能跳转到登录页，或显示“权限不足”。这并不绝对安全，需要进一步测试。
深入测试情况B：
- 检查Cookie/Session：管理员和普通用户的会话标识可能有区别。尝试将普通用户的Cookie中的role或level字段（如果存在且可被篡改）修改为admin或1。
- 测试API接口：/admin/userList.php可能只是一个前端页面，数据通过AJAX从后端API获取，例如/api/admin/getUsers。直接尝试调用这个API接口，可能绕过前端页面的权限检查。
- 请求方法绕过：有时权限检查只针对GET方法。尝试用POST、PUT等方法访问同一个路径，可能会有意外收获。

4.3 一个真实的逻辑缺陷案例

某次审计中，我发现一个系统的权限判断逻辑如下：

# 伪代码 if request.path.startswith('/admin/'): if not current_user.is_authenticated: return redirect('/login') if not current_user.role == 'admin': return render_template('403.html') # 返回无权限页面 # 执行管理员操作

看起来没问题？但系统还有一个“超级管理员”功能模块，路径是/superadmin/。开发者在检查时，只写了startswith('/admin/')，而遗漏了/superadmin/路径。导致任何登录用户（无需admin角色）都能直接访问/superadmin/下的所有功能，造成了严重的垂直越权。

挖掘技巧：在目录扫描时，思维要发散。不要只扫常见目录，要结合应用特点。比如一个教育系统，可以尝试/teacher/、/headmaster/；一个电商系统，可以尝试/merchant/、/operator/。

5. 案例三：结合业务逻辑的复杂越权漏洞挖掘

越权漏洞的“高级玩法”往往与具体的业务逻辑深度绑定。这类漏洞的挖掘，要求测试者不仅是一个“黑客”，更要是一个“业务专家”。我们来看两个需要动脑子的例子。

5.1 案例A：密码重置流程中的“Token与邮箱解绑”

这是一个非常经典的业务逻辑越权案例，我们详细拆解。

正常流程：

用户在忘记密码页面输入邮箱victim@example.com。
系统向该邮箱发送一封邮件，内含一个一次性重置链接，如https://target.com/reset?token=abc123。
用户点击链接，进入重置页面。页面表单里可能有一个隐藏的email字段，值为victim@example.com，或者后端从token对应的缓存记录中读取邮箱。
用户输入新密码，提交。后端验证token有效且未过期，然后将victim@example.com的密码更新。

漏洞流程：

攻击者访问忘记密码页面，输入自己的邮箱attacker@example.com。
攻击者收到重置链接https://target.com/reset?token=def456。
攻击者点击链接，进入重置页面。此时，攻击者打开浏览器开发者工具或使用Burp Suite拦截提交新密码的POST请求。
攻击者发现，POST请求的参数中除了new_password和confirm_password，还有一个email参数，其值当前是attacker@example.com。
关键步骤：攻击者将email参数的值修改为victim@example.com，而token参数保持不变（token=def456），然后提交请求。
漏洞触发：后端服务器收到请求后，执行了如下有缺陷的逻辑：
- 验证token=def456有效（因为它确实是系统刚发给攻击者的合法token）。
- 但后端没有检查这个token是否与提交的email参数绑定。它直接使用请求中的email参数（victim@example.com）作为要重置密码的账户。
- 于是，系统将受害者victim@example.com的密码重置为攻击者设定的新密码。

漏洞根源：密码重置的token，必须与最初申请重置的邮箱账号在服务器端进行强绑定。验证时，应该用token去查对应的邮箱，而不是接受客户端传来的邮箱。正确的逻辑是：reset_email = cache.get(token); if reset_email != submitted_email: error。

5.2 案例B：订单流程中的“平行权限”滥用

在某电商平台，用户下单后可以申请“仅退款”（不退货）。流程如下：

用户A对订单1001申请仅退款。
商家审核拒绝。
用户A可以对此拒绝决定进行“申诉”，提交补充材料。

漏洞场景：

用户B也有一个被拒绝退款的订单1002。
用户B在提交申诉时抓包，发现请求中包含参数order_id=1002和appeal_reason=...。
用户B将order_id修改为1001（用户A的订单），然后提交。
后端检查发现：订单1001的退款申请确实被拒绝了（状态符合），并且当前登录用户B“有订单”（但没检查是不是这个订单），于是允许了申诉操作。
结果：用户B成功以自己身份，为用户A的订单发起了申诉，可能干扰平台判责或泄露申诉信息。

漏洞根源：在申诉这个子流程中，后端只校验了“订单是否处于可申诉状态”，但没有严格校验“发起申诉的用户是否是该订单的所属用户”。这属于业务流程中权限校验的缺失。

挖掘这类漏洞的心得：

绘制业务流程图：对于核心业务（登录注册、支付、订单、审核、提现等），亲手画一画它的正常流程。
寻找状态转换点：关注那些能改变业务状态的环节，如“提交审核”、“确认收货”、“发起退款”、“撤销申请”。这些环节往往是权限校验的关键点。
问自己两个问题：在这个环节，系统如何知道“你是谁”？系统如何确定“你有权操作这个对象”？如果这两个问题的答案依赖于前端参数、可预测的ID或是不完整的校验，那么漏洞就可能存在。

6. 越权漏洞的自动化辅助与高级挖掘技巧

手动测试是基础，但效率和深度离不开工具的辅助和一些进阶思路。

6.1 工具链配置与使用

Burp Suite - Intruder（爆破与模糊测试）：
- 用途：自动化修改参数并发送大量请求，用于发现有效的ID范围、遍历目录、测试权限参数。
- 配置示例：针对id参数，设置Payload类型为“Numbers”，从1到1000，步长为1。然后根据响应长度、状态码或关键词（如“订单号”、“用户名”）来筛选可能成功的请求。
- Cluster bomb攻击类型：当需要同时测试两个相关参数时（如user_id和order_id），可以设置两个Payload集，进行组合测试。
Burp Suite - Scanner（被动扫描）：
- 在浏览网站过程中，Burp会自动分析流量，有时能标记出潜在的IDOR（不安全的直接对象引用）点。但这只是提示，需要手动验证。

自定义脚本（Python）：

对于复杂的业务逻辑测试或需要处理会话、Token的场景，编写Python脚本会更灵活。
示例任务：自动完成“获取重置Token -> 篡改邮箱 -> 提交重置”的全流程测试。

import requests # 1. 使用攻击者邮箱获取token s = requests.Session() resp1 = s.post('https://target.com/forgot', data={'email': 'attacker@mail.com'}) # (假设通过邮件或API获取token，这里简化) token = 'abc123' # 2. 使用该token，但尝试重置受害者邮箱 resp2 = s.post('https://target.com/reset', data={'token': token, 'email': 'victim@mail.com', # 篡改的参数 'new_password': 'Hacked123!'}) if 'success' in resp2.text: print("[!] 可能存在密码重置越权漏洞！")

6.2 高级技巧：参数污染、时间竞争与间接引用

HTTP参数污染：当后端同时接收来自多个位置的同名参数时（如URL查询参数和POST body中都有user_id），处理逻辑可能出现混乱。尝试在GET参数和POST参数中提供不同的id值，观察后端以哪个为准，这有可能绕过某些校验。
时间竞争条件：在某些并发操作中，权限检查和使用资源不是原子操作。例如：
- 用户A发起“转账给B”的请求，后端先检查A的余额是否充足（通过），但在扣款前有一瞬间延迟。
- 在同一瞬间，用户A急速发起另一个“转账给C”的请求。
- 如果后端没有做好并发锁，两次检查可能都通过，导致A用一笔钱完成了两笔转账。这本质上是越权使用了“未来的余额”。
间接对象引用：有时，前端显示的不是真正的数据库ID，而是一个经过编码或映射的“引用ID”。你需要尝试找出其编码/解码规律。例如，订单号显示为ORD-ABC123，在请求中却是id=789。你需要测试789是否对应其他用户的订单。或者，尝试对ORD-ABC123进行简单的变换，如ORD-ABC124、ORD-ABD123，看是否能访问到其他数据。

6.3 漏洞挖掘思维框架

我将越权测试总结为一个四步循环的思维框架：

标识定位：找到所有标识用户、资源、操作对象的参数。不仅是数字ID，还包括UUID、用户名、邮箱、文件名、哈希值等。
请求操纵：系统地修改这些参数。包括：递增/递减、替换为同权限其他用户/资源标识、替换为高权限标识（如admin）、置空、删除参数、重复参数、使用非法字符等。
差异分析：仔细观察每次请求的响应。对比状态码、响应长度、响应时间、返回数据内容、错误信息。任何差异都可能是突破口。
逻辑推理：基于差异，推测后端校验逻辑。是完全没有校验？是校验了但可以被绕过？还是校验逻辑存在缺陷？然后设计新的测试用例去验证你的推测。

7. 常见问题排查与防御方案实录

在挖掘和修复越权漏洞的过程中，会遇到各种“坑”。这里记录一些典型问题和解决方案。

7.1 漏洞挖掘中的常见“假阳性”与排查

响应状态码都是200，但内容不同：修改ID后，服务器可能返回了一个通用的错误页面或空数据模板，状态码仍是200。不要只看状态码，要对比响应体内容、长度。使用Burp的“Comparer”工具进行差异对比非常高效。
依赖全局登录状态：测试越权时，务必确保你的每个测试请求都携带了正确的会话Cookie（Session Cookie）或Token。有时在Burp Repeater中不小心清除了Cookie，会导致请求被视为未登录而返回302跳转，这容易被误判为“权限校验有效”。
CSRF Token干扰：很多表单提交带有CSRF Token。如果你在Repeater中重放一个旧请求，Token可能已失效。需要先GET一次表单页面，获取新的Token，再构造POST请求。自动化测试时，需要编写脚本处理这种动态Token。
请求频率限制：大量爆破ID可能会触发IP或账号的速率限制。需要调整工具的发包间隔，或者使用代理池。

7.2 开发者视角：如何从根本上防御越权漏洞

作为开发者，必须在设计之初就树立“永不信任客户端”的原则。

最小权限原则：每个功能、每个API接口，在代码层面明确定义其所需的最小权限。

服务端强制校验：所有涉及资源访问的操作，必须在服务端进行“用户-资源”所有权或权限关联校验。

正确代码示例（Python Flask + SQLAlchemy）：

@app.route('/api/order/<int:order_id>', methods=['GET']) @login_required def get_order(order_id): current_user_id = session.get('user_id') # 关键：查询时关联当前用户ID order = Order.query.filter_by(id=order_id, user_id=current_user_id).first() if not order: return jsonify({'error': 'Order not found or access denied'}), 404 return jsonify(order.to_dict())

使用不可预测的标识符：避免使用连续的数字ID作为资源标识。可以使用UUID、随机生成的字符串，或者对数字ID进行加密签名（如JWT），并在服务端验证签名的有效性。

统一的权限检查中间件/装饰器：对于Web应用，可以设计一个全局的权限检查中间件。对于API，可以使用装饰器。将权限校验逻辑集中管理，避免在每个函数里重复编写和遗漏。

# 权限装饰器示例 def check_ownership(model_class, id_param='id'): def decorator(func): @wraps(func) def wrapper(*args, **kwargs): obj_id = kwargs.get(id_param) current_user = get_current_user() obj = model_class.query.filter_by(id=obj_id, user_id=current_user.id).first() if not obj: raise PermissionDeniedError() return func(*args, **kwargs) return wrapper return decorator @app.route('/post/<int:post_id>/delete', methods=['POST']) @login_required @check_ownership(Post) # 使用装饰器自动检查 def delete_post(post_id): # ... 删除逻辑，到这里已经确认用户有权删除此post pass

定期进行代码审计与渗透测试：将越权检查作为代码审查和自动化安全测试（SAST/DAST）的必选项。定期邀请安全团队或使用第三方工具进行黑盒/白盒测试。

7.3 对测试者的建议：编写有效的漏洞报告

当你发现一个越权漏洞后，一份清晰、可复现的报告至关重要。

标题明确：直接点明漏洞类型和位置，如“【高危】XX系统用户资料修改功能存在水平越权漏洞”。
详细复现步骤：
- 测试账号信息（可匿名化）。
- 具体的操作步骤（点击哪里，输入什么）。
- 关键的HTTP请求和响应（用代码块展示，脱敏敏感数据）。
- 证明漏洞存在的截图或视频。
影响分析：说明这个漏洞能导致什么后果（如查看他人隐私、篡改他人数据、提升权限等）。
修复建议：提供具体的代码修复方案，参考上面的防御措施。这能极大提升你的专业度，并帮助开发团队快速解决问题。

越权漏洞的挖掘是一场与开发者逻辑思维的博弈。从简单的ID修改到复杂的业务逻辑绕过，其核心始终在于理解“系统认为你是谁”和“系统允许你做什么”之间的校验是否严密。保持好奇心，多问“如果...会怎样”，并辅以系统的测试方法，你就能在纷繁复杂的Web应用中，找到那些不该存在的“权限后门”。

查看全文

http://www.jsqmd.com/news/1077178/