Pikachu靶场越权漏洞实战：从原理到利用的完整权限提升指南-平芜编程栈

1. 项目概述：为什么越权漏洞是渗透测试的“黄金门票”

在网络安全领域，渗透测试人员或安全研究员常常需要一个安全、可控的环境来磨练自己的技能，这就是“靶场”存在的意义。Pikachu靶场，作为一个集成了多种Web漏洞的综合性学习平台，因其漏洞类型全面、环境搭建简单而广受欢迎。在众多漏洞类型中，越权漏洞（Broken Access Control）因其危害性大、隐蔽性高，常被列为高危漏洞。它不像SQL注入或XSS那样需要复杂的Payload构造，有时仅仅是一个请求参数的修改，就能让一个普通用户瞬间获得管理员的至高权限。因此，掌握越权漏洞的挖掘与利用，是每一位安全从业者从“脚本小子”迈向“实战高手”的必经之路。

本次实战，我们将聚焦于Pikachu靶场中的越权漏洞模块，目标非常明确：从一个名为“pikachu”的普通用户身份出发，通过技术手段，突破系统设计的权限边界，最终获取到“admin”管理员账户的权限。这个过程不仅仅是点击几个按钮，更重要的是理解漏洞背后的逻辑缺陷、掌握Burp Suite等工具在实战中的灵活运用，并形成一套可复用的漏洞挖掘思路。无论你是刚入门的安全爱好者，还是希望巩固基础的安全工程师，这篇从普通用户到管理员的完整权限提升实录，都将为你提供清晰的路径和宝贵的实操经验。

2. 环境准备与漏洞原理深度解析

2.1 Pikachu靶场搭建与核心模块定位

工欲善其事，必先利其器。首先，我们需要一个可操作的Pikachu靶场环境。Pikachu通常以PHP+MySQL的Web应用形式提供，你可以从其官方GitHub仓库下载源码。搭建过程对于有基础的开发者而言并不复杂：将源码放置于Web服务器根目录（如Apache的htdocs或Nginx的html目录），导入附带的SQL文件以初始化数据库，最后修改数据库连接配置文件即可。对于新手，使用Docker或集成环境如PHPStudy、XAMPP是更快捷的选择，它们能一键解决环境依赖问题。

注意：在本地搭建靶场是学习的最佳实践，切勿在未授权的真实网站上进行测试，这不仅是职业道德，更是法律红线。

启动靶场后，访问本地地址（如http://localhost/pikachu），你会看到一个充满卡通风格的界面。我们的目标是“越权漏洞”模块。在Pikachu中，它通常被清晰地分类在漏洞列表中。点击进入，你会发现它可能细分为“垂直越权”和“水平越权”两个子模块。垂直越权（Vertical Privilege Escalation）是我们的主战场，它指的是低权限用户（如普通用户pikachu）获取了高权限用户（如管理员admin）才能执行的功能。而水平越权（Horizontal Privilege Escalation）则是同一权限等级的用户之间，非法访问了他人的数据，例如用户A看到了用户B的订单信息。

2.2 越权漏洞的本质：信任与验证的失衡

要利用漏洞，必须先理解漏洞。越权漏洞产生的根源，在于服务端对客户端请求的处理逻辑存在缺陷。一个健康的权限检查流程应该是：接收请求 → 验证会话/令牌权限 → 检查请求资源是否属于当前用户或在其权限范围内 → 执行操作。而存在越权漏洞的流程，往往缺失或错误地实施了中间的关键步骤。

具体到Pikachu靶场的案例，其漏洞原理可以这样拆解：

前端伪装：Web页面上的按钮、链接可能根据登录角色动态显示或隐藏。例如，“添加用户”按钮只对管理员显示。但这仅仅是前端控制。
后端失守：当用户发起请求（如点击“添加用户”按钮触发HTTP请求）时，服务端代码没有二次严格校验发起该请求的用户身份是否真的有权限执行此操作。它可能只检查了用户是否登录（即是否有有效的会话），但没有检查这个登录的用户角色是否是“admin”。
参数可控：请求中的关键参数（如执行操作的类型、操作的目标对象ID）可能由用户控制，并且服务端过度信任这些参数，未将其与当前用户身份进行绑定校验。

这种“前端限制，后端放任”或“校验不严”的设计，就是越权漏洞滋生的温床。攻击者只需要利用工具截获一个高权限的请求，然后用自己的低权限会话去“重放”这个请求，就可能直接绕过所有前端限制，完成越权操作。

3. 实战演练：步步为营实现垂直越权

3.1 信息收集与正常业务流程观察

任何一次成功的渗透都始于细致的信息收集。首先，我们分别使用两个已知账户登录系统：

管理员账户：用户名admin，密码在Pikachu靶场中通常是admin或123456。
普通用户账户：用户名pikachu，密码同样可能是pikachu或123456。

登录后，仔细观察两者界面的差异。以管理员身份登录，你很可能在用户管理、系统设置等模块看到“添加用户”、“删除用户”、“修改权限”等高级功能菜单。而以pikachu身份登录，这些菜单应该消失或不可点击。我们的任务就是，在pikachu的会话下，找到并执行这些本不该出现的功能。

接下来，开启你的侦查工具——Burp Suite。确保浏览器代理已正确配置到Burp（如127.0.0.1:8080），并开启Burp的代理拦截（Intercept is on）和流量记录（Proxy -> HTTP history）。然后，切换回管理员账号，执行一个典型的特权操作，例如“添加一个新用户”。在点击“添加”或“提交”按钮时，Burp会截获这个HTTP请求。

3.2 请求截获与关键参数分析

假设我们截获到的管理员添加用户的POST请求如下：

POST /pikachu/vul/overpermission/op2/op2_admin_edit.php HTTP/1.1 Host: localhost Cookie: PHPSESSID=admin_session_id_here; username=admin Content-Type: application/x-www-form-urlencoded username=testuser&password=Test123&sex=1&phonenum=13800138000&email=test@test.com&add=%E6%B7%BB%E5%8A%A0

现在，我们需要像侦探一样分析这个请求：

身份标识：Cookie头中的PHPSESSID和username=admin是服务端识别当前会话和用户的关键。漏洞利用的关键就在于，我们能否在替换了这些身份标识后，依然使请求成功。
操作参数：请求体（Body）中的username,password,add等参数，定义了要执行的操作（添加）和操作的内容（新用户信息）。服务端是否只依赖这些参数执行操作，而忽略了验证操作者身份？
URL路径：/op2_admin_edit.php这个文件路径名本身就暗示了它是管理员编辑功能，但服务端是否真的在文件入口处校验了调用者角色？

分析完毕后，在Burp Suite的拦截窗口中，右键将这个请求发送到“Repeater”模块。Repeater允许我们手动修改并重复发送请求，是测试漏洞的利器。

3.3 漏洞利用：会话替换与请求重放

现在，我们退出管理员账号，用普通用户pikachu重新登录。登录后，查看Burp的HTTP history，找到pikachu登录成功后的请求，记下其新的PHPSESSID和Cookie中可能存在的username=pikachu字段。

回到Burp的Repeater标签页，里面保存着我们刚才截获的管理员添加用户请求。现在，我们要进行“偷梁换柱”：

将请求头中的Cookie值，替换为刚刚记录的pikachu用户的Cookie值（例如：PHPSESSID=pikachu_session_id_here; username=pikachu）。
为了确保请求完全来自pikachu的视角，你还可以将请求体中的内容稍作修改，比如把要添加的用户名从testuser改为hacked_by_pikachu，以区分测试结果。
点击“Send”按钮，发送这个修改后的请求。

激动人心的时刻到了：观察右侧的响应（Response）面板。如果漏洞存在，你可能会看到诸如“添加成功”、“用户创建成功”之类的字样，并且HTTP状态码很可能是200 OK。这意味着，服务器接受了来自pikachu会话的“添加用户”请求，并成功执行了！

为了验证，你可以回到Pikachu靶场的用户管理页面（如果pikachu账号有查看用户列表的权限），或者直接尝试用新添加的账号hacked_by_pikachu登录。如果登录成功，那么恭喜你，一次经典的垂直越权攻击就完成了。pikachu这个普通用户，已经拥有了创建新用户的系统管理员权限。

3.4 漏洞利用的另一种形式：参数篡改

除了上述的“请求重放”，越权漏洞还可能表现为“参数篡改”。例如，在一个“查看个人信息”的功能中，URL可能形如/userinfo.php?id=1001。普通用户pikachu的ID是1001，他访问这个链接看到自己的信息。服务端可能只检查了用户是否登录，但没有检查id=1001这个参数是否与当前登录用户的ID匹配。

如果pikachu将URL中的id参数改为1002（假设是另一个用户或管理员的ID），服务器可能就直接返回了用户1002的敏感信息，这就构成了水平越权。在垂直越权场景中，可能会存在诸如role=admin、action=deleteUser这样的参数，直接修改它们也可能触发权限提升。

在Pikachu靶场中，你可以尝试寻找这类带参数的GET或POST请求，在Repeater中修改参数值，观察响应变化。这种测试方法通常与重放测试结合使用。

4. 工具进阶：利用Burp Suite提高测试效率

4.1 Intruder模块在越权测试中的妙用

当面对大量需要测试的接口或参数时，手动在Repeater中修改发送效率太低。Burp Suite的Intruder模块正是为这种自动化、批量化测试而生的。例如，我们怀疑一个用户详情接口/api/user/profile?userId=存在水平越权。我们可以这样操作：

定位请求：在Proxy history中找到访问自己个人资料的请求，发送到Intruder。
设置攻击点：在Intruder的Positions标签页，清除默认攻击点，然后选中URL中的userId参数值，点击“Add §”将其标记为攻击点（Payload Position）。例如，请求会变成/api/user/profile?userId=§1001§。
配置Payload：切换到Payloads标签页。假设我们想测试用户ID从1000到1010的情况。在Payload type中选择“Numbers”，然后设置From 1000， To 1010， Step为1。这样会生成11个数字作为Payload。
开始攻击：点击“Start attack”。Intruder会自动用这11个不同的userId值替换攻击点，并发起请求。
分析结果：攻击完成后，表格会显示每个请求的响应状态码、长度、内容。我们需要重点关注那些状态码为200但响应长度与我们自己请求（userId=1001）不同的条目。如果发现某个其他userId的请求也返回了完整的用户信息（且非错误信息），那么水平越权漏洞就存在了。

实操心得：在分析Intruder结果时，响应长度（Length）是一个非常重要的快速筛选指标。通常，越权成功和失败的页面内容大小会有明显差异。结合状态码和响应内容预览，能快速定位可疑请求。

4.2 Scanner的辅助探测与漏洞确认

Burp Suite的主动扫描器（Scanner）也能辅助发现越权漏洞，尤其是对于常见的、模式化的漏洞点。你可以将某个经过身份验证后的功能页面（如用户管理列表页）的URL发送给Scanner进行主动扫描。

Scanner会尝试自动探测诸如“不安全的直接对象引用”（IDOR，即参数篡改类越权）等问题。它可能会报告“Possible Insecure Direct Object Reference”之类的漏洞。但是，必须注意：自动扫描器的结果误报率较高，尤其是对于业务逻辑复杂的越权漏洞。Scanner的提示只能作为一个线索，最终的漏洞确认必须依靠手动测试，即我们前面在Repeater或Intruder中进行的请求修改与重放验证。绝不能仅凭扫描报告就断定漏洞存在。

5. 漏洞挖掘思路拓展与防御之道

5.1 超越靶场：真实场景中的越权漏洞挖掘

Pikachu靶场为我们提供了一个完美的实验环境，但真实世界的应用要复杂得多。以下是一些拓展性的挖掘思路：

关注API接口：现代Web应用前后端分离，业务逻辑通过API（如/api/v1/user/delete）实现。使用浏览器开发者工具的“网络”（Network）面板，捕获所有AJAX/XHR请求。这些API端点往往是越权漏洞的高发区。
测试所有HTTP方法：不要只盯着GET和POST。尝试将POST请求改为PUT、DELETE、PATCH等方法，或者反之。有时权限校验只针对某种方法配置。
寻找隐藏参数与接口：通过爬虫工具（如Burp的Spider）或分析前端JS代码，寻找未在页面上直接暴露的功能接口。这些“影子API”由于不被前端使用，后端校验可能更松懈。
组合漏洞利用：越权漏洞常与其他漏洞结合产生更大危害。例如，先通过一个反射型XSS获取管理员的Cookie（需配合其他漏洞），再利用该Cookie发起越权请求。或者，在一个可越权上传文件的功能点，上传Webshell，从而获得服务器控制权。

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

作为渗透测试者，理解防御方案不仅能帮助你更全面地评估风险，也能在提交漏洞报告时给出有价值的修复建议。防御越权漏洞的核心原则是“服务端强制校验”：

实施最小权限原则：每个功能、每个API接口，在代码层面明确定义其所需的角色或权限等级。
进行访问控制检查：在每一个处理用户请求的服务器端入口函数（Controller/Action）的最开始，加入统一的权限校验逻辑。不是简单地检查“是否登录”，而是检查“当前登录的用户是否有权执行此操作”。
绑定用户上下文：对于涉及用户自身数据的操作（如修改个人信息、查看订单），必须在服务端将请求参数（如用户ID）与当前登录会话中的用户ID进行强制比对，确保一致。
使用安全的间接引用映射：避免直接使用数据库主键等可预测值作为资源标识符（如/order/123）。可以使用随机生成的UUID，或通过一个服务端维护的、与用户会话绑定的映射表来转换。
定期进行代码审计与渗透测试：在开发流程中引入安全代码审查和定期的渗透测试，主动发现并修复逻辑漏洞。

6. 常见问题排查与实战避坑指南

在实战测试中，你可能会遇到各种“意外”，导致看似应该成功的攻击失败了。下面是一些常见问题及排查思路：

问题现象	可能原因	排查与解决思路
替换Cookie后请求返回登录页面或403错误	1. 会话失效或无效。 2. 服务端除了Cookie，还可能校验了其他Token（如CSRF Token）。 3. 请求头需要其他认证信息。	1. 确认使用的Cookie是目标用户（pikachu）最新、有效的会话ID。重新登录获取。 2. 检查原始管理员请求的HTML表单或请求体中，是否包含名为`csrf_token`、`authenticity_token`等字段，重放时需一并携带。 3. 检查是否有`X-Requested-With`、`Authorization`等特殊请求头需要保留。
请求成功（返回200），但操作未实际生效（如用户未添加）	1. 服务端进行了二次验证（如验证操作人角色），但错误提示不明确。 2. 操作触发了业务逻辑错误（如用户名已存在），但被通用成功页面掩盖。 3. 数据库操作失败。	1. 仔细阅读响应体，寻找隐藏的错误信息或不同的成功提示。 2. 尝试不同的测试数据（如全新的用户名、邮箱）。 3. 查看服务器端日志（如果可能），这是定位问题最直接的方式。
只能越权查看，不能越权修改/删除	权限校验粒度不同。服务端可能对“读”操作校验宽松，对“写”操作校验严格。	这是常见的防御不彻底现象。确认漏洞影响范围，读越权（信息泄露）和写越权（数据篡改）通常属于不同危险等级，在报告中需明确区分。
在Intruder测试中，所有请求返回相同结果	1. Payload位置设置错误。 2. 服务器对频繁请求进行了限制或封禁。 3. 会话在测试过程中过期。	1. 检查Intruder的Positions，确保攻击点（§ §）标记在了正确的参数值上。 2. 在Intruder的Options标签页，增加请求间隔（Throttle），或更换代理IP。 3. 使用Burp的“Session Handling Rules”功能，在攻击中自动维持会话。

独家避坑技巧：在测试越权漏洞时，养成“对比分析”的习惯。分别用低权限和高权限账户执行同一操作，用Burp的“Compare”功能对比两个请求的原始报文和响应报文。差异点（如不同的Header、参数、响应结构）往往就是权限校验的关键所在。此外，对于修改操作，务必进行“回滚”测试，即验证操作是否真的在系统层面生效，而不是仅仅返回了一个成功的假象。

最后，我想分享一点个人体会：越权漏洞的挖掘，三分靠工具，七分靠思维。它考验的是你对业务逻辑的理解深度和对“信任边界”的敏感度。Pikachu靶场是一个绝佳的起点，但它模拟的是理想化的漏洞场景。真正的实战环境更加复杂和隐蔽，需要你不断将这里学到的原理和方法举一反三，在每一次测试中，都多问一句：“服务器真的相信这个请求来自一个有权这样做的人吗？” 带着这个疑问去审视每一个交互点，你会发现更多意想不到的安全隐患。