1. 项目概述从“越权查看”到权限体系的深度认知在安全测试和渗透学习的圈子里Webug靶场是一个绕不开的名字。它就像我们学车时的“科目二”场地把那些在真实Web应用中常见的、却又容易被忽视的安全漏洞一个个单独拎出来做成一个个独立的“考题”让我们可以安全地、反复地练习和琢磨。今天我们要啃的这块硬骨头就是“越权查看”。这听起来可能不如SQL注入、XSS那么“炫酷”但它在实际业务中的危害和普遍性绝对不容小觑。简单来说越权查看就是一个用户看到了他不该看到的数据。比如你登录了一个论坛只能看自己的私信但通过某种方式你看到了别人的私信或者在一个电商后台你是一个普通客服却看到了公司CEO的订单数据。这种漏洞的核心是应用程序在数据访问控制上“偷了懒”或者“想当然”了。服务器端没有严格校验“当前请求的用户”是否有权限访问“他请求的这份数据”仅仅因为用户通过了登录认证就对他“有求必应”。Webug靶场里的这个越权查看关卡就是把这个场景高度抽象和简化后呈现给我们。它不会用复杂的业务逻辑来迷惑你而是直指问题的核心一个脆弱的、依赖于前端比如URL参数来判定数据归属的查询接口。我们的目标就是绕过这个脆弱的前端控制直接与服务器“对话”拿到那些本不属于我们的信息。这个过程不仅是学习一个漏洞的利用更是理解现代Web应用权限模型RBAC、ABAC等为何如此重要的绝佳入口。无论你是刚入门的安全爱好者还是想巩固基础的开发人员把这个漏洞吃透都能让你对“数据安全”这四个字有更深刻的理解。2. 漏洞原理深度拆解为什么“前端不可信”在动手之前我们必须把原理吃透。很多新手会困惑我明明登录了系统怎么还会让我看别人的数据这里的关键在于区分两个概念身份认证Authentication和授权Authorization。身份认证解决的是“你是谁”的问题。输入用户名密码、扫码、刷脸都是为了向系统证明“我是张三”。系统验证通过后会给你一个凭证比如Session ID或JWT Token之后的每次请求都带着它系统就知道是“张三”在操作。授权解决的是“你能干什么”的问题。即使你是张三系统也要判断张三有权限删除李四的帖子吗有权限查看王五的工资条吗越权漏洞就发生在授权这个环节。具体到“越权查看”它属于访问控制漏洞的一种通常是因为服务器端在进行数据查询时缺失了或错误地实施了权限校验逻辑。2.1 水平越权与垂直越权这里需要明确两个子类型虽然Webug这个关卡主要演示水平越权但理解两者区别很重要水平越权Insecure Direct Object References IDOR指相同权限等级的用户之间能够非法访问彼此的数据。这是最常见的越权类型。例如用户A和用户B都是普通用户用户A通过修改请求参数如订单ID、用户ID访问到了本属于用户B的订单详情页面。漏洞根源在于服务器仅验证了用户已登录但没有验证“当前登录用户ID”与“请求数据的目标用户ID”是否匹配。注意IDOR这个术语在OWASP TOP 10中历史上很常见它精准地描述了“不安全的直接对象引用”这一设计缺陷。垂直越权指低权限用户能够执行高权限用户的操作或访问高权限数据。例如一个普通用户通过构造请求访问到了管理员的后台功能页面。这通常意味着角色的权限隔离出现了严重问题。Webug的“越权查看”关卡就是一个典型的水平越权IDOR场景。2.2 漏洞产生的典型代码模式我们来看看在开发中是什么样不经意的代码导致了这个问题。假设一个查看个人笔记的功能脆弱的后端代码伪代码示例// 从请求中直接获取笔记ID例如/view_note.php?id123 $note_id $_GET[‘id’]; // 连接数据库 $conn new mysqli(...); // 直接根据ID查询笔记内容没有关联用户 $sql “SELECT title, content FROM notes WHERE id ‘“ . $note_id . “‘“; $result $conn-query($sql); if ($row $result-fetch_assoc()) { echo “标题” . $row[‘title’]; echo “内容” . $row[‘content’]; } else { echo “笔记不存在”; }这段代码的问题一目了然它从用户可控的输入$_GET[‘id’]中直接获取了对象笔记的标识符ID然后去数据库查询。整个过程中完全没有检查当前登录的用户假设通过Session已识别是不是这个笔记的主人。攻击者只需要遍历id参数如123124125…就能看到所有用户的笔记。正确的后端代码应该是什么样session_start(); // 假设用户登录后其用户ID存储在$_SESSION[‘user_id’]中 $current_user_id $_SESSION[‘user_id’]; $note_id $_GET[‘id’]; // 查询时将笔记ID和当前用户ID作为联合条件 $sql “SELECT title, content FROM notes WHERE id ? AND user_id ?“; $stmt $conn-prepare($sql); $stmt-bind_param(“ii”, $note_id, $current_user_id); // 使用参数化查询防止SQL注入 $stmt-execute(); $result $stmt-get_result(); if ($row $result-fetch_assoc()) { // 显示笔记 } else { // 要么笔记不存在要么不属于当前用户统一返回“无权限或不存在” echo “访问被拒绝或笔记不存在”; }关键区别在于正确的代码在数据访问层数据库查询就加入了权限校验AND user_id ?确保取出的数据一定是属于当前登录用户的。这就是“服务端强制访问控制”的核心思想。2.3 为什么前端传递的参数不可信这是本漏洞原理中最需要敲黑板的一点。在Webug关卡中你可能会在页面的URL、隐藏的表单字段hidden input、或者JavaScript变量里看到类似uid1这样的参数。这些参数明确地指示了要查看哪个用户的数据。一个致命的误解是开发人员可能会认为“这个uid是从我们自己的页面链接里带过来的是安全的”或者“用户看不到修改的地方就安全”。这是完全错误的。任何从客户端浏览器传递到服务器端的数据都是完全可控的。包括URL中的查询字符串?uid1POST请求体中的表单数据HTTP请求头如Cookie、Referer虽然通常不这么用甚至URL路径本身如RESTful API的/user/1/profile攻击者可以轻松地使用浏览器开发者工具F12、Burp Suite、Postman甚至简单的cURL命令来修改这些参数的值。因此权限校验绝对不能依赖于任何来自客户端的、指示目标对象归属的标识符。校验的依据必须且只能是服务器端会话Session中存储的、经过认证的当前用户身份信息。3. 靶场环境搭建与初步侦察工欲善其事必先利其器。在开始“攻击”之前我们需要一个安全的实验环境。强烈建议在虚拟机如VMware、VirtualBox中搭建靶场与主机隔离。3.1 Webug靶场部署Webug靶场通常是一个PHP项目。部署过程相对简单准备环境安装集成环境软件如PHPStudy、XAMPP或WAMP。这些软件会一次性安装好Apache、PHP、MySQL。确保你的PHP版本在5.4以上MySQL在5.5以上以兼容Webug。获取源码从可靠的来源如GitHub上的官方仓库或安全社区分享下载Webug靶场的源码压缩包。部署项目将解压后的Webug文件夹复制到你的Web服务器根目录下例如PHPStudy的WWW目录XAMPP的htdocs目录。访问靶场打开浏览器输入http://localhost/webug/或http://127.0.0.1/webug/。如果看到Webug的首页说明部署成功。初始化数据库首次访问时通常需要根据页面提示初始化数据库。这个过程会创建必要的数据库、数据表并插入漏洞演示用的初始数据包括测试账号。请严格按照页面指引操作。实操心得部署时最常见的两个坑一是端口冲突比如80端口被占用二是PHP扩展没开如mysql或mysqli。如果页面报错先检查Apache/Nginx是否启动成功再查看PHP错误日志。数据库初始化后建议记下自动创建的几个测试账号和密码比如admin/admin,test/123456等后续登录会用到。3.2 目标关卡定位与界面分析成功进入Webug后你会看到一个漏洞列表目录。找到“越权漏洞”或“访问控制”相关的分类里面应该有一个名为“越权查看”或类似描述的关卡点击进入。进入关卡后不要急着动手。先像正常用户一样操作一遍理解业务流程登录使用关卡提供的测试账号如user1/pass1登录系统。理解你在这个系统中的角色例如普通会员。观察功能点登录后找到那个可能触发越权的功能。通常是一个“查看个人信息”、“我的订单”、“我的文章”之类的链接。点击它。分析请求这是最关键的一步。打开浏览器开发者工具F12切换到Network网络标签页并确保它处于记录状态Record button是红色的。然后点击那个功能链接或按钮。捕捉请求在网络面板中你会看到一个新的HTTP请求记录。点击它查看详细信息。你需要关注以下几个部分Request URL请求URL看看URL里面有没有像id,uid,userid这样的参数。例如http://localhost/webug/vul/view.php?uid1。Request Method请求方法是GET还是POSTGET请求的参数在URL里POST请求的参数在请求体里。Query String Parameters / Form Data查询字符串参数/表单数据这里会清晰地列出所有客户端发送给服务器的参数及其值。Response响应服务器返回了什么是HTML页面还是JSON数据返回的数据里是否包含了敏感信息如其他用户的姓名、邮箱、手机号通过这一步你已经完成了第一次“侦察”。你知道了漏洞可能存在的接口地址、传递参数的方式和参数名。接下来就是思考如何“篡改”它。4. 漏洞利用实战手动与工具双视角理解了原理摸清了地形现在可以开始实战了。我们将从最简单的手动修改到使用专业工具进行高效测试。4.1 手动利用浏览器直接修改这是最直观的方法适合理解漏洞的本质。场景假设你以user1用户ID假设为1的身份登录访问“我的信息”页面URL显示为http://target/view.php?uid1页面正确显示了user1的信息。攻击步骤直接修改浏览器地址栏中的URL将uid1改为uid2。按下回车发起新的请求。观察页面。可能的结果与分析结果A成功显示用户2的信息。恭喜你发现了最典型的IDOR漏洞服务器完全没有校验uid参数是否属于当前登录用户。结果B返回“无权限”或跳转到登录页/首页。这说明服务器做了某种程度的校验。但这并不绝对安全需要进一步测试。结果C返回“用户不存在”或空白页。这可能意味着用户2确实不存在也可能意味着校验更严格。可以尝试其他ID如uid3,uid100等。注意事项手动修改URL适用于GET请求。如果参数是通过POST请求发送的在请求体里你就不能直接在地址栏改了。这时候就需要用到下面介绍的工具。4.2 专业工具利用Burp Suite实战Burp Suite是Web安全测试的“瑞士军刀”。用它来测试越权效率和信息量都远超手动修改。前期准备启动Burp Suite确保Proxy代理监听已开启默认127.0.0.1:8080。配置浏览器代理使其流量经过Burp。以Chrome为例可以安装SwitchyOmega插件或直接使用Burp自带的浏览器更方便。在Burp的Proxy - Intercept标签页确保“Intercept is on”是打开状态。测试流程拦截请求在浏览器中用user1账号登录然后点击“查看我的信息”按钮。这个请求会被Burp拦截下来。分析并修改请求在Burp的拦截界面你会看到完整的HTTP请求。如果是GET请求你可以在请求行第一行的URL里直接修改参数。如果是POST请求你可以在最下面的请求体Request body里找到类似uid1namexxx的参数并进行修改。我们将uid1改为uid2。GET /webug/vul/view.php?uid2 HTTP/1.1 // 修改了uid参数 Host: localhost Cookie: PHPSESSIDabc123... // 这个Cookie代表了user1的登录会话 ...其他头部信息放行并观察点击“Forward”放行这个被修改的请求。然后切换到浏览器查看页面显示内容。如果显示了用户2的信息漏洞存在。使用Repeater模块进行高效测试拦截-修改-放行这个流程对于单个测试还行但效率不高。更高效的做法是在Proxy - HTTP history中找到刚才那个正常的view.php?uid1请求。右键点击它选择“Send to Repeater”。切换到Repeater标签页这里你可以随意修改请求参数然后点击“Send”发送右侧会实时显示服务器的响应。你可以快速地将uid修改为2,3,4,100…进行批量测试并对比响应内容。使用Intruder模块进行自动化模糊测试当需要测试大量可能的ID时Intruder是神器。在Repeater或History中右键请求选择“Send to Intruder”。切换到Intruder - Positions标签页Burp通常会自动标记一些参数。我们只关心uid所以点击“Clear”清除所有标记然后手动选中uid参数的值比如数字1点击“Add”将其标记为攻击载荷位置。它会变成uid§1§的样子。切换到Payloads标签页。在Payload type中选择“Numbers”。设置From为1To为100Step为1。这将会生成1到100的数字序列作为payload。点击右上角的“Start attack”开始攻击。Intruder会使用1到100依次替换uid的值并发起100次请求。攻击完成后一个结果表会出现。你需要重点关注Length响应长度和Status状态码这两列。通常成功的越权请求返回了其他用户数据的响应长度会与失败的请求返回错误页或无数据显著不同。通过排序和对比你可以快速筛选出哪些ID是可访问的。4.3 漏洞利用的多种变形越权查看不一定只通过uid这一个参数。在实际应用中它可能以各种形式出现文件名或路径遍历查看用户上传的文件时参数可能是fileuser1_report.pdf。尝试修改为fileuser2_report.pdf。数字ID的变形ID可能不是简单的整数而是经过编码或哈希。例如idabc123。虽然不能直接递增但如果你能通过自己的ID如idabc123对应user1推断出编码规律就可能破解出user2的ID如iddef456。POST请求中的越权修改个人信息的功能提交的POST数据里可能包含userid1。虽然前端表单里这个字段是隐藏的input type“hidden” name“userid” value“1”但用Burp Suite可以轻松修改它并提交从而修改其他用户的信息这就从“越权查看”升级为“越权修改”了。JSON/XML API中的越权现代前端应用常通过API与后端交互。请求体可能是JSON格式{“userId”: 1, “action”: “getProfile”}。同样用工具修改userId的值即可测试。5. 漏洞挖掘与拓展测试思路发现一个简单的uid参数越权只是开始。一个优秀的安全测试者需要思考如何系统地发现这类漏洞以及它可能与其他漏洞产生怎样的“化学反应”。5.1 如何系统性地寻找IDOR漏洞参数收集使用爬虫工具如Burp的Scanner OWASP ZAP或手动浏览收集应用中所有包含ID类参数的请求。关注参数名如id,uid,userid,account,file,doc,order,invoice,message等。功能点分析重点关注所有“增删改查”功能特别是“查”和“改”。列出所有涉及个人数据的页面和API端点。测试每一个点对收集到的每个可疑请求使用Burp Repeater系统地修改其ID参数观察响应变化。不仅要测试“存在”的用户ID也要测试“不存在”的、过大的、负数的ID观察错误处理是否合理是否泄露信息。关注间接引用有时对象不是直接通过ID引用而是通过名称、邮箱等唯一标识符。测试修改这些参数同样有效。5.2 越权漏洞的“组合技”单纯的越权查看危害已经不小但如果能结合其他漏洞危害会呈指数级放大。越权 批量枚举Intruder如上所述利用Intruder可以自动化地遍历大量用户ID从而一次性窃取大量用户数据造成大规模数据泄露。越权 敏感信息泄露在越权查看的响应中仔细检查返回的HTML源码或JSON数据。开发者有时会把所有字段数据都返回给前端再由前端JavaScript决定显示哪些。通过越权请求你可能会拿到包含手机号、身份证号、地址等未在页面上显示的敏感字段。水平越权 - 垂直越权在某些设计不良的系统中普通用户和管理员的区别可能仅仅是一个role字段或type字段。如果你在修改个人信息时发现可以修改自己的role参数并将其从user改为admin那么你就通过水平越权修改自己的数据实现了垂直越权提升为管理员。这通常发生在更新个人资料的API没有对role等敏感字段进行过滤。越权查看 - 越权操作很多操作是关联的。例如你先通过越权查看拿到了一个其他用户的高权限订单ID或票据ID。然后你可能会在另一个功能点如“取消订单”、“下载票据”使用这个窃取来的ID进行操作从而实现越权操作。5.3 针对API的特别测试对于返回JSON的RESTful API测试方法类似但观察点不同修改请求参数同样使用Repeater修改ID。分析响应结构关注HTTP状态码。200 OK不一定代表成功要看响应体里的业务状态码如{“code”: 0, “msg”: “success”, “data”: {...}}。403 Forbidden通常代表权限校验生效。404 Not Found可能代表对象不存在或无权访问需结合返回信息判断。测试HTTP方法尝试将GET /api/user/1改为PUT /api/user/1或DELETE /api/user/1看看是否能越权修改或删除数据。测试权限边界使用高权限用户如管理员的Token去访问低权限用户的专属API或者反过来。这能测试权限系统的上下边界是否牢固。6. 防御方案设计与代码实现作为开发者知道了漏洞如何产生更重要的是知道如何避免。防御越权漏洞的核心原则是在服务器端进行强制访问控制且该控制必须基于不可篡改的服务器端信息。6.1 黄金法则服务端校验不可少无论前端做了多少隐藏、禁用、混淆后端都必须对每一次数据访问请求进行权限校验。校验逻辑必须放在业务逻辑层或数据访问层绝不能依赖客户端传来的任何关于权限判定的标识。6.2 具体防御策略基于所有权Ownership的校验 这是防御水平越权最直接有效的方法。在查询/操作数据库时将当前会话中的用户标识如$_SESSION[‘user_id’]作为查询条件的一部分。// 安全示例查询当前用户的订单 $current_user_id get_current_user_id_from_session(); // 从安全会话中获取 $order_id $_GET[‘order_id’]; $stmt $pdo-prepare(“SELECT * FROM orders WHERE id :order_id AND user_id :user_id”); $stmt-execute([‘:order_id’ $order_id, ‘:user_id’ $current_user_id]); $order $stmt-fetch(); if (!$order) { // 统一返回“未找到”或“无权限”避免信息泄露 http_response_code(404); exit(‘Resource not found’); } // 后续才处理$order数据基于角色/权限RBAC/ABAC的校验 对于垂直越权或更复杂的场景需要在业务逻辑入口处进行角色或权限检查。// 安全示例检查用户是否有‘delete_user’权限 if (!has_permission($current_user_id, ‘delete_user’)) { http_response_code(403); exit(‘Forbidden’); } // 执行删除用户逻辑...使用间接引用映射Indirect Reference Maps 不直接使用数据库主键如自增ID作为对外暴露的标识符。而是对外暴露一个随机的、无规律的令牌Token在服务器端维护一个映射关系。对外用户访问/view?token7a9b8c3d1e对内服务器根据token7a9b8c3d1e查映射表得到内部order_id105和user_id12然后再进行所有权校验。 这种方式即使攻击者拿到了一个token也无法通过规律猜测其他token。统一的访问控制层/中间件 在Web框架中最佳实践是设计一个统一的访问控制中间件或装饰器。在请求进入具体的控制器Controller或动作Action之前就进行权限校验。# Flask框架示例使用装饰器 from functools import wraps def check_owner(resource_type): def decorator(f): wraps(f) def decorated_function(resource_id, *args, **kwargs): current_user get_current_user() # 根据resource_type和resource_id查询所有者是否为current_user if not is_owner(current_user, resource_type, resource_id): return ‘Forbidden’, 403 return f(resource_id, *args, **kwargs) return decorated_function return decorator app.route(‘/order/int:order_id‘) check_owner(‘order’) # 在进入视图函数前进行校验 def view_order(order_id): # 这里可以安全地相信order_id属于当前用户 order Order.query.get(order_id) return render_template(‘order.html’, orderorder)安全的默认配置与错误处理最小权限原则数据库连接用户、应用运行账户只拥有必要的最小权限。默认拒绝访问控制列表ACL应默认拒绝所有访问再显式允许特定权限。模糊错误信息无论是资源不存在还是无权限访问尽量返回统一的错误信息如“资源未找到”避免泄露系统状态如“您无权查看该订单”就暗示了订单存在。6.3 代码审计中的危险信号在代码审计时看到以下模式要立即警惕数据库查询语句中WHERE条件里没有与当前用户关联的条件。直接从$_GET,$_POST,$_REQUEST获取对象ID后直接用于查询、更新或删除操作。使用了前端传递的“角色”、“权限等级”等字段来判断是否允许执行某个操作。文件操作函数如file_get_contents(),readfile()的参数直接来自用户输入且没有检查文件路径是否在允许范围内。7. 从靶场到实战企业级渗透测试中的越权检查在真实的企业渗透测试或众测中测试越权漏洞的思路需要更全面、更系统并且要严格遵守测试范围和法律边界。7.1 测试流程与方法论信息收集与资产梳理使用子域名枚举、目录扫描等工具尽可能发现所有可访问的Web应用和API端点。使用爬虫如Burp Suite的爬虫、gospider遍历整个应用绘制出功能点地图和所有可能的参数点。用户角色与权限建模注册或获取至少两个不同权限级别的测试账号如普通用户、VIP用户、内容编辑、系统管理员。如果可能获取更多同级别账号。手动使用每个账号浏览应用理解每个角色被允许访问的功能和数据范围。记录下每个功能点对应的URL和参数。自动化与手动结合测试自动化辅助使用Burp Suite的Scanner或定制插件对爬取到的所有请求进行基础的参数模糊测试Fuzzing自动替换常见的ID参数。这可以帮助发现“低垂的果实”。手动深度测试自动化工具无法理解业务逻辑。对于核心业务功能如支付、订单、个人信息、管理后台必须进行手动测试。同角色测试水平用UserA的凭证登录访问所有UserA的功能。同时用Burp抓取这些请求。然后用UserB的凭证登录将UserA的请求中的ID参数如订单号、消息ID替换为UserB的对应ID发送请求看是否能访问到UserA的数据。跨角色测试垂直用低权限账号UserLow登录尝试访问仅高权限账号UserHigh或管理员可见的URL或API。这包括直接访问管理后台URL、调用管理员API等。测试状态与无状态API有状态Session测试时确保每个角色的测试都在独立的浏览器会话或Burp Suite的不同User Context中进行避免Cookie串扰。无状态JWT/Token对于使用JWT的API需要分别使用不同角色的Token进行测试。重点关注JWT的Payload部分是否包含角色role或用户IDsub信息并思考服务器端是否完全信赖这些信息进行鉴权。7.2 漏洞报告撰写要点发现漏洞后一份清晰、专业的报告至关重要。标题简明扼要如“[水平越权] 普通用户可通过修改order_id参数查看任意用户订单详情”。风险等级通常定为“中危”或“高危”取决于可越权访问的数据敏感性和影响范围。漏洞详情目标URL提供完整的漏洞请求URL。请求方法GET/POST/PUT等。脆弱参数指出哪个参数存在缺陷如order_id。重现步骤按1,2,3…列出从登录到触发漏洞的详细步骤。包括使用的测试账号、操作顺序、修改的参数值。必须附上Proof of Concept (PoC)可以是截图显示修改请求和成功响应的Burp界面也可以是能直接重放的HTTP请求包Curl命令或Burp的Copy as curl command。请求与响应示例提供修改前后的HTTP请求和响应原始数据可脱敏。影响分析说明这个漏洞能导致什么后果例如“可导致所有用户的订单信息含收货地址、手机号泄露”。修复建议给出具体的、可操作的修复方案参考第6部分的防御策略。例如“建议在/api/order/detail接口的数据库查询中增加AND user_id #{currentUserId}条件。”7.3 实战中的注意事项与边界遵守授权范围绝对不要测试授权范围之外的系统或功能。不要使用非提供的测试账号进行暴力破解或注册。数据安全在测试过程中可能会接触到真实的用户数据在授权测试中。严禁下载、保存、传播这些数据。测试完成后应及时清理本地缓存和记录。谨慎使用自动化工具避免使用扫描器对生产环境进行高强度、高频次的扫描这可能被视为DoS攻击。应在测试环境或获得明确许可的情况下进行。最小化影响以证明漏洞存在为目的不要进行破坏性操作。例如越权删除测试应使用无关紧要的测试数据或在最后一步中止。理解并掌握越权漏洞是构建安全Web应用的基石。从Webug靶场这个简单的uid参数修改开始我们一路深入到原理、利用、挖掘、防御和实战其核心思想始终如一永远不要信任客户端。作为开发者要将权限校验深深刻入服务器端逻辑的骨髓作为安全研究者则要带着这份“不信任”去审视每一个数据交互的环节。这个漏洞看似简单却像一面镜子能清晰地照出一个系统在访问控制上的成熟度。