1. 项目概述与核心思路最近在带新人做安全测试练习发现很多朋友对“越权漏洞”这个概念理解得比较模糊尤其是垂直越权。理论看了一大堆一到实战就不知道怎么下手。正好Pikachu靶场里有一个非常经典的垂直越权漏洞场景非常适合用来练手。今天我就结合这个靶场手把手带你走一遍完整的流程核心就是教你如何用BurpSuite这个“瑞士军刀”去抓包、分析、并修改Cookie最终实现从普通用户权限“越级”到管理员权限的操作。这不仅仅是完成一个靶场练习更是理解Web应用权限控制缺陷的绝佳案例。无论你是刚入门安全测试的新手还是想巩固基础的老手跟着这个流程走一遍你都能对Cookie在身份认证中的作用、越权漏洞的成因和利用方法有一个非常直观和深刻的认识。简单来说这个实战的目标很明确在一个模拟的Web系统Pikachu靶场中我们首先会以普通用户“lucy”的身份登录。然后通过BurpSuite拦截系统发出的HTTP请求找到其中用于标识用户身份的Cookie。最关键的一步来了——我们会尝试将这个Cookie的值修改为另一个更高权限用户比如管理员“admin”的会话标识。如果系统在设计时仅仅依赖客户端传来的Cookie来判断用户身份而没有在服务端做严格的二次校验那么我们的修改就可能欺骗服务器让它误以为我们是管理员从而执行一些原本只有管理员才能进行的操作比如添加新用户。这就是一次典型的垂直越权攻击。整个过程的精髓在于对HTTP协议交互的观察和操控而BurpSuite正是实现这种操控的利器。2. 环境准备与工具配置2.1 Pikachu靶场搭建Pikachu靶场是一个使用PHP/MySQL开发的、专门用于Web漏洞学习和演练的开源项目。它集成了SQL注入、XSS、CSRF、越权等常见漏洞环境依赖简单非常适合在本地搭建。首先你需要一个基础的Web运行环境。我推荐使用PHPStudy、XAMPP或WAMP这类集成环境包它们一键安装Apache、PHP和MySQL省去大量配置时间。这里以PHPStudy为例下载与安装从PHPStudy官网下载最新版本并安装。安装路径建议不要有中文和空格比如D:\phpstudy_pro。启动服务打开PHPStudy在“首页”标签页启动Apache和MySQL服务。确保它们的状态显示为绿色“运行中”。部署靶场下载Pikachu靶场的源码压缩包通常是一个ZIP文件。解压后将整个pikachu文件夹复制到PHPStudy的网站根目录下。对于PHPStudy V8版这个目录通常是D:\phpstudy_pro\WWW\。初始化数据库打开浏览器访问http://localhost/pikachu。首次访问时页面会提示你“数据库没有连接请先进行初始化安装”。点击该链接或按钮进入初始化页面。通常你只需要点击“安装/初始化”按钮即可。Pikachu会自动创建所需的数据库和表并插入演示数据。验证安装初始化成功后刷新页面你应该能看到Pikachu靶场的主界面左侧是漏洞分类菜单。找到并点击“越权漏洞”-“垂直越权”我们的实战舞台就准备好了。注意如果初始化失败请检查PHPStudy中的MySQL服务是否真的启动成功以及PHP的版本。Pikachu对PHP 5.4和7.x版本兼容性较好遇到问题可以尝试切换PHP版本。2.2 BurpSuite配置与浏览器代理设置BurpSuite是本次实战的核心工具它是一个用于攻击Web应用程序的集成平台。我们主要用到它的代理Proxy和重放Repeater功能。获取BurpSuite从PortSwigger官网下载社区版免费或专业版。社区版功能对于本次学习和大多数基础测试已经足够。启动与基础配置首次启动BurpSuite它会让你选择临时项目或保存项目按默认选择即可。进入主界面后我们需要先配置代理监听。切换到Proxy标签页然后进入Options子标签。确保Proxy Listeners中有一条监听器默认是127.0.0.1:8080且状态为Running。如果没有可以点击“Add”添加绑定地址Bind to address选127.0.0.1端口Port用8080。浏览器代理设置要让浏览器的流量经过BurpSuite需要配置浏览器代理。以Chrome为例Firefox配置类似安装浏览器插件如SwitchyOmega或直接使用系统代理设置。我更喜欢用SwitchyOmega配置一个情景模式代理协议为HTTP代理服务器为127.0.0.1端口为8080。然后将其设置为活动模式。简单方法也可以直接在Windows系统设置中搜索“代理”手动设置HTTP代理为127.0.0.1:8080。安装BurpSuite证书重要配置好代理后用浏览器访问任意HTTP网站如http://example.comBurpSuite会拦截到请求。但访问HTTPS网站如https://google.com会显示证书错误因为BurpSuite在中间对HTTPS流量进行了解密和再加密。为了解决这个问题需要安装BurpSuite的CA证书到浏览器受信任的根证书颁发机构。在浏览器中访问http://burp或http://127.0.0.1:8080。点击 “CA Certificate” 按钮下载证书文件cacert.der。将证书导入到操作系统或浏览器的受信任根证书存储中。具体步骤因操作系统和浏览器而异网上有详细教程这一步至关重要否则无法拦截HTTPS流量。验证代理完成证书安装后确保BurpSuite的Intercept is on按钮是按下状态拦截开启然后访问http://localhost/pikachu。你应该能在BurpSuite的Proxy - Intercept标签页看到拦截到的HTTP请求。点击“Forward”可以放行请求。这说明代理配置成功。3. 漏洞原理与场景深度解析3.1 什么是垂直越权在深入操作之前我们必须把原理吃透。越权漏洞主要分为水平越权和垂直越权两类。水平越权指相同权限级别的用户之间能够非法访问或操作本不属于自己的数据。例如用户A能查看或修改用户B的订单、个人信息等。问题出在服务端没有对数据访问进行“属主”校验。垂直越权这是我们本次实战的重点。它指的是低权限用户能够执行高权限用户才能执行的操作。例如一个普通论坛会员通过某种手段获得了版主或管理员的权限可以进行删帖、封禁用户等操作。垂直越权的危害通常比水平越权更大因为它直接破坏了整个系统的权限层级体系。垂直越权的根本原因在于服务端对客户端提交的请求在处理敏感操作时完全信任或过度依赖客户端提供的信息如Cookie、参数来判断用户的权限而没有在服务端会话Session中重新、严格地校验当前执行操作的用户是否真正拥有该权限。3.2 Cookie、Session与身份认证要理解如何利用Cookie实现越权必须清楚Cookie和Session在Web登录中的作用。Session会话当用户成功登录后服务器端会为该用户创建一个唯一的Session对象里面存储了该用户的登录状态、用户ID、角色权限等信息。这个Session有一个唯一的ID称为Session ID。Cookie因为HTTP协议是无状态的服务器需要一种方式在多次请求中识别同一个用户。于是在创建Session后服务器会将这个Session ID通过响应头Set-Cookie发送给用户的浏览器。身份维持浏览器收到这个Cookie里面包含了Session ID后会将其保存起来。之后该浏览器向同一网站发起的每一个HTTP请求都会自动通过请求头Cookie将这个Session ID带回给服务器。权限判定服务器收到请求后通过请求中的Session ID找到对应的服务器端Session对象然后从Session中读取用户的身份和权限信息从而决定是否允许执行当前请求的操作。漏洞产生的关键点如果系统在判断用户是否有权进行“添加用户”这个操作时逻辑是这样的// 错误示范直接从客户端Cookie取用户名判断权限 $username $_COOKIE[username]; if ($username admin) { // 允许添加用户 } else { // 拒绝操作 }这段代码的致命缺陷是它信任了客户端传来的Cookie: usernameadmin。攻击者完全可以修改这个Cookie值。正确的做法应该是// 正确示范从服务端Session取用户名判断权限 session_start(); $username $_SESSION[username]; // Session中的信息存储在服务器用户无法直接修改 if ($username admin) { // 允许添加用户 }Pikachu靶场的垂直越权模块模拟的就是第一种错误逻辑。它可能将用户名直接明文放在了Cookie里或者使用了一个可预测、可篡改的Token来标识用户身份和权限。3.3 Pikachu靶场垂直越权场景分析进入Pikachu靶场的“垂直越权”模块我们通常会看到两个功能链接“查看用户列表”和“添加用户”。页面上可能还会显示当前登录的用户比如“lucy”。正常流程用户“lucy”登录服务器设置一个Cookie例如Cookie: usernamelucy; leveluser。“lucy”点击“查看用户列表”可以正常查看。“lucy”点击“添加用户”提交请求。服务器检查请求中的Cookie发现usernamelucy, leveluser于是拒绝该操作返回“权限不足”。攻击流程目标用户“lucy”登录。在发起“添加用户”请求时使用BurpSuite拦截该请求。将请求中的Cookie修改为管理员的标识例如Cookie: usernameadmin; leveladmin。将修改后的请求发送给服务器。服务器检查Cookie看到usernameadmin便认为这是管理员在操作于是执行添加用户的逻辑。越权成功。我们的实战就是要完整再现这个攻击流程并理解其中每一个环节。4. 实战操作手把手利用BurpSuite实现越权4.1 第一步正常登录与观察首先我们以普通用户身份进行正常操作目的是熟悉流程并捕获关键的请求数据。在浏览器中访问Pikachu的垂直越权页面 (http://localhost/pikachu/vul/overpermission/vertical/vertical.php)。使用提供的测试账号登录。在Pikachu中通常会有预设账号比如普通用户lucy/password管理员admin/123456。我们先用lucy登录。登录成功后注意观察页面变化。页面上可能会显示“欢迎lucy”之类的提示。更重要的是打开浏览器的开发者工具F12切换到“网络(Network)”或“应用程序(Application)”标签查看当前站点的Cookie。你应该能看到一个或多个由localhost设置的Cookie。记录下它们的名称和值例如你可能看到usernamelucy或者一个看起来像乱码的PHPSESSIDabc123def...。这一步是了解系统如何标识用户的关键。4.2 第二步配置BurpSuite进行抓包现在我们要让BurpSuite开始工作。确保BurpSuite的代理监听已开启浏览器代理已正确指向BurpSuite。在BurpSuite的Proxy - Intercept标签页确认Intercept is on按钮是红色按下状态表示拦截功能开启。回到浏览器在已登录的状态下点击页面上那个“添加用户”的按钮或链接。注意先不要填写任何添加用户的信息只是点击这个链接让它触发一个请求。此时BurpSuite的Intercept界面会立即捕获到这个HTTP请求并暂停转发。你看到的就是浏览器发出的“请求添加用户页面”的GET请求。实操心得很多新手在这一步会直接去填表单提交然后抓不到想要的包。原因是“点击添加用户链接”和“提交添加用户表单”是两个独立的请求。前者通常是GET请求用于加载表单页面后者是POST请求包含了你填写的用户名、密码等数据。我们首先要分析的是第一个GET请求看看Cookie是如何传递的。如果这个页面加载时就已经根据Cookie判断了权限并返回了不同的页面内容比如直接返回无权限提示那我们的攻击点可能就在这个GET请求上。如果它返回了表单那么攻击点就在后续的POST请求上。Pikachu的漏洞通常设计在POST请求的处理逻辑中。4.3 第三步分析请求与定位关键Cookie在BurpSuite拦截到的请求中我们需要仔细研究请求头。GET /pikachu/vul/overpermission/vertical/vertical_add.php HTTP/1.1 Host: localhost User-Agent: Mozilla/5.0... Accept: text/html,application/xhtmlxml... Accept-Language: zh-CN,zh;q0.8,zh-TW;q0.7... Accept-Encoding: gzip, deflate Connection: close Cookie: usernamelucy; leveluser; PHPSESSID6f5q7s8t9u0v1w2x3y4z Upgrade-Insecure-Requests: 1重点关注Cookie:这一行。在这个例子中模拟Pikachu可能的情况我们看到三个Cookie项usernamelucy这很可能就是系统用来判断用户身份的字段。太明显了leveluser这直接表明了用户的权限等级。PHPSESSID...这是PHP的标准会话ID。如果系统正确使用了Session权限信息应该存储在服务器端与该PHPSESSID对应的Session中那么只修改客户端的username和level是没用的。但Pikachu为了演示漏洞其代码逻辑可能直接读取了username这个Cookie值而忽略了PHPSESSID对应的真实Session。我们的假设这个靶场的漏洞代码逻辑是在处理vertical_add.php的请求时无论是GET还是POST直接从$_COOKIE[‘username’]或$_COOKIE[‘level’]中取值来判断权限而不是从$_SESSION中取。4.4 第四步修改Cookie并重放请求这是攻击的核心步骤。我们将尝试把低权限的Cookie替换成高权限的。在BurpSuite的Intercept界面直接修改请求头中的Cookie值。将usernamelucy改为usernameadmin将leveluser改为leveladmin。修改后请求头如下Cookie: usernameadmin; leveladmin; PHPSESSID6f5q7s8t9u0v1w2x3y4z注意PHPSESSID保持不变因为我们不确定服务端是否同时验证了Session。先尝试只修改明显的身份标识字段。修改完成后点击Forward按钮将这个修改后的请求发送给服务器。切换到浏览器观察页面变化。可能会出现几种情况情况A成功浏览器直接显示了一个“添加用户”的表单页面而之前用lucy账号点击时可能显示的是“权限不足”或直接跳转。这说明GET请求的权限校验已经绕过。情况B仍需POST页面显示了表单但提交表单时还需要再次绕过校验。这很正常我们继续。4.5 第五步实施越权操作添加用户如果上一步成功看到了添加用户的表单那么最关键的权限关卡已经过了。现在我们来完成添加用户的操作。在浏览器显示的表单中填写你想要添加的新用户信息例如用户名test_user密码test_pass。在点击表单的“提交”或“添加”按钮之前再次确保BurpSuite的拦截是开启的Intercept is on。点击提交按钮。BurpSuite会拦截到这次POST请求。分析拦截到的POST请求。它应该长这样POST /pikachu/vul/overpermission/vertical/vertical_add.php HTTP/1.1 Host: localhost Content-Type: application/x-www-form-urlencoded Content-Length: 35 Cookie: usernamelucy; leveluser; PHPSESSID6f5q7s8t9u0v1w2x3y4z usernametest_userpasswordtest_pass注意这个POST请求的Cookie依然是lucy的这是因为浏览器自动携带了当前站点的Cookie。我们需要再次修改它。将POST请求中的Cookie也修改为管理员的值Cookie: usernameadmin; leveladmin; PHPSESSID6f5q7s8t9u0v1w2x3y4z请求体usernametest_userpasswordtest_pass保持不变。点击Forward发送修改后的POST请求。4.6 第六步验证攻击结果发送请求后切换到浏览器查看响应。直接观察响应BurpSuite在拦截模式下你可以在Proxy - HTTP history标签页找到刚才发送的POST请求查看其响应Response。如果响应中包含了“添加成功”、“用户创建成功”等字样或者没有明显的错误信息则很可能成功了。功能验证回到Pikachu靶场的“查看用户列表”页面。刷新页面看看列表中是否出现了你刚刚添加的test_user。如果出现了那么恭喜你垂直越权攻击成功完成你以普通用户lucy的身份通过篡改Cookie成功执行了管理员才能做的“添加用户”操作。5. 漏洞根因分析与修复建议5.1 漏洞代码逻辑推测基于我们的攻击过程可以反向推断出Pikachu靶场中漏洞代码的大致逻辑仅为教学模拟存在漏洞的vertical_add.php处理逻辑可能如下// vertical_add.php (漏洞版本) // 判断是否有权限执行添加操作 $username $_COOKIE[username]; // 错误直接从Cookie取用户身份 $level $_COOKIE[level]; // 错误直接从Cookie取用户等级 if ($level ! admin) { die(权限不足); } // 执行添加用户的数据库操作 if ($_SERVER[REQUEST_METHOD] POST) { $new_user $_POST[username]; $new_pass md5($_POST[password]); // 简单MD5加密仅作示例 // ... 执行INSERT语句 ... echo 用户 $new_user 添加成功; }这段代码的致命问题在于它完全信任了客户端传来的Cookie。攻击者可以轻易伪造Cookie。5.2 正确的权限校验方式安全的做法必须基于服务器端会话Session。修复后的vertical_add.php逻辑应如下// vertical_add.php (安全版本) session_start(); // 开启会话 // 判断用户是否登录检查Session中是否存在登录标识 if (!isset($_SESSION[is_login]) || $_SESSION[is_login] ! true) { header(Location: login.php); exit(); } // 判断用户是否为管理员从Session中读取用户角色 if ($_SESSION[user_role] ! admin) { // ‘user_role’在登录时存入Session die(权限不足); } // 执行添加用户的数据库操作 if ($_SERVER[REQUEST_METHOD] POST) { // 这里还可以增加CSRF Token校验防止跨站请求伪造 if (!validate_csrf_token($_POST[token])) { die(非法请求); } $new_user $_POST[username]; $new_pass password_hash($_POST[password], PASSWORD_DEFAULT); // 使用强哈希 // ... 使用参数化查询防止SQL注入 ... echo 用户 $new_user 添加成功; }核心修复点使用Session而非Cookie存储敏感信息用户登录状态is_login、用户ID、角色user_role等关键信息应存储在服务器端的Session中。Session ID是唯一桥梁客户端仅通过Cookie持有无法被篡改的Session ID如PHPSESSID。服务器通过这个ID找到对应的Session数据进行校验。关键操作双重校验对于任何敏感操作增删改查服务端在处理请求时都必须从当前请求关联的Session中重新获取用户身份和权限进行校验绝不能依赖URL参数、POST表单字段或Cookie中的用户标识。补充安全措施如使用CSRF Token防止跨站请求伪造使用预处理语句防止SQL注入使用强密码哈希算法等。6. 实战扩展与防御思考6.1 使用BurpSuite的Repeater模块进行高效测试在实战中我们使用了Intercept拦截模式。但在更复杂的测试中频繁开关拦截会影响正常浏览。BurpSuite的Repeater重放器模块是更强大的工具。在Proxy的HTTP history中找到你感兴趣的请求比如lucy的添加用户POST请求。右键点击该请求选择Send to Repeater。切换到Repeater标签页你可以看到这个请求被完整地复制过来了。在这里你可以随意修改请求的任何部分URL、参数、Cookie、Headers然后点击Send按钮右侧会立即显示服务器的响应。你可以多次修改、多次发送对比响应结果无需拦截浏览器流量效率极高。这对于测试不同Cookie值、参数组合非常方便。6.2 自动化测试思路Intruder模块如果我们需要批量测试多个可能的Cookie值例如猜测管理员的用户名或Session ID手动修改效率太低。BurpSuite的Intruder入侵者模块可以自动化这个过程。将目标请求发送到Intruder。在Positions标签页清除所有自动标记的变量然后手动选中Cookie中你想要爆破的部分比如username后面的值lucy点击“Add”将其设为攻击变量。在Payloads标签页设置Payload。例如我们可以用一个简单的字典包含admin,root,administrator,superuser等常见管理员用户名。点击“Start attack”。Intruder会自动用字典中的每个值替换变量发送大量请求并记录每个请求的响应状态码、长度、内容等。通过分析响应比如响应长度突然变长、内容里出现了“添加成功”等关键字我们可以快速判断哪个Payload即哪个用户名让服务器返回了成功的页面。6.3 针对越权漏洞的防御 checklist作为一名开发者在设计和评审代码时应时刻警惕越权漏洞。以下是一份简单的自查清单检查项安全做法风险做法身份认证所有敏感操作前必须从服务器端Session中校验用户登录状态 ($_SESSION[‘is_login’])。通过Cookie、URL参数、隐藏表单字段传递用户ID。权限校验执行操作前从Session中获取当前用户的角色/权限与操作所需权限进行比对。根据客户端上传的用户ID或角色参数进行权限判断。数据归属查询、修改、删除数据时SQL语句中必须包含当前用户ID作为条件如WHERE user_id :current_user_id。仅根据客户端提供的目标数据ID进行操作不校验该数据是否属于当前用户。直接对象引用避免使用连续的、可预测的ID如1,2,3。使用随机、不可预测的UUID或对ID进行加密混淆。使用?id123这样的参数直接访问资源。日志与监控记录所有敏感操作的日志包括操作者、时间、IP、具体动作。定期审计异常操作。没有操作日志或日志不完整无法追溯攻击行为。6.4 从攻击者视角到防御者视角的转变完成这个实战练习最大的收获不仅仅是学会了一个攻击技巧。更重要的是它强制你从“数据流”的角度去思考一个Web应用请求从哪里来浏览器请求里带了什么URL、Headers、Cookie、Body服务器相信了什么它选择信任了请求中的哪些部分服务器根据什么做决定是根据它自己内存Session里的数据还是客户端送来的数据当你习惯用这种视角去审视一个功能时无论是进行安全测试还是开发你都能一眼看出那些“信任了不该信任的东西”的代码。这才是学习漏洞利用的真正价值——不是为了攻击而是为了在构建系统时能主动避免这些陷阱写出更健壮、更安全的代码。