1. 项目概述理解越权漏洞的本质在Web安全测试的日常工作中越权漏洞Broken Access Control是出现频率极高、危害性极大的一类问题。它不像SQL注入或XSS那样需要复杂的构造很多时候仅仅是因为开发人员对用户权限的边界检查不够严格就为攻击者打开了通往敏感数据或功能的大门。简单来说越权就是“你做了你不该做的事”或者“你看了你不该看的东西”。根据权限跨越的方向我们通常将其分为水平越权和垂直越权。水平越权也叫作“平行越权”指的是攻击者能够访问或操作与其权限级别相同、但本应属于其他用户的资源。比如在一个社交网站中你通过修改URL中的用户ID参数成功看到了另一个普通用户的私密相册这就是典型水平越权。垂直越权则更为危险它指的是低权限用户如普通会员能够执行高权限用户如管理员才能进行的操作。例如一个论坛的普通用户通过某种方式访问到了后台管理员的删除帖子功能接口这就构成了垂直越权。为什么这类漏洞如此普遍根源在于“信任边界”的模糊。开发者在设计功能时往往默认用户会“规规矩矩”地使用前端界面而忽略了后端对每一个请求都必须进行严格的权限复核。前端隐藏了一个按钮不代表后端接口就安全了用户登录时验证了身份不代表后续每个操作都无需再次确认其权限。这种“默认安全”的思维正是越权漏洞滋生的温床。对于安全研究员、渗透测试工程师乃至开发人员而言透彻理解这两种越权的原理、掌握其挖掘方法是构建或评估一个健壮应用安全体系的必修课。2. 核心原理深度剖析权限模型的失效点要挖掘漏洞必须先理解漏洞产生的根源。越权漏洞的本质是应用程序的访问控制机制存在缺陷未能正确执行最小权限原则。让我们拆开来看这两种越权的技术原理。2.1 水平越权横向权限边界的缺失水平越权的核心问题在于应用程序在处理用户对数据对象的访问请求时没有验证“当前请求的用户是否是该数据对象的合法所有者”。其常见的技术实现漏洞点包括基于标识符的不安全直接对象引用IDOR这是最常见的形式。应用程序使用可预测的序列如递增的用户ID、订单号、文档ID作为资源标识。后端接口接收到如/api/user/profile?uid123的请求时直接根据uid123去数据库查询并返回数据而没有检查当前会话用户假设其uid是456是否有权限查看uid123的资料。攻击者只需遍历或猜测这些ID就能访问到大量其他用户的敏感信息。功能级水平越权某些功能本身并不直接关联特定数据对象但也不应该被所有同角色用户随意使用。例如一个“重置收货地址”的功能后端如果没有验证该地址是否属于当前用户攻击者就可能通过篡改请求中的地址ID参数将其他用户的地址修改或删除。多阶段流程中的权限泄露在一个多步骤的操作中如订单支付流程可能在第一步验证了权限但在后续的步骤如查看支付结果详情中仅凭一个步骤生成的令牌token或ID就返回数据而不再校验该令牌与当前用户的关联性。注意水平越权不一定需要“登录”。在某些设计不当的系统中即使未登录如果资源标识如一个分享链接的ID被猜解或泄露也可能直接访问到未授权的资源这有时也被归类为“未授权访问”但其原理与水平越权相通。2.2 垂直越权纵向权限校验的旁路垂直越权比水平越权危害更大因为它可能导致整个系统被控制。其原理在于应用程序未能区分不同权限等级用户的访问边界。常见漏洞模式包括隐藏接口与功能暴露管理员功能的前端界面可能对普通用户隐藏如通过CSS的display:none或直接不渲染但对应的后端API接口依然存在且可以被直接访问。如果该接口仅通过前端隐藏来“保护”而没有在后端进行角色或权限校验就会造成垂直越权。例如普通用户直接访问/admin/deleteUser.php可能就能执行删除操作。参数篡改与权限提升请求中可能包含标识用户角色的参数。例如在注册或修改用户信息的请求中有一个roleuser的参数。如果后端完全信任这个来自客户端可能被篡改的参数攻击者将其改为roleadmin并提交就可能直接将自己提升为管理员。不安全的权限继承与配置在复杂的系统或使用某些框架时可能存在默认配置不安全的情况。例如某个Web框架的路由配置中默认所有认证用户都可以访问某个管理前缀的路由而开发人员忘记添加额外的角色拦截器。平行权限与交叉越权这是一种特殊场景。系统可能存在多个平行的权限角色如“教师”和“学生”。一个“学生”角色用户通过漏洞访问到了本该只有“教师”角色才能使用的功能如发布作业这也属于垂直越权因为这是在两个不同权限等级之间的跨越。理解这些原理后我们就能像攻击者一样思考系统在哪里区分用户在哪里校验权限这些校验是否可以被绕过这些点就是我们的重点测试目标。3. 实战漏洞挖掘方法论从黑盒到灰盒掌握了原理接下来就是如何在实际的Web应用中发现这些漏洞。我个人的经验是采用一种从“黑盒”到“灰盒”的渐进式挖掘思路效率最高。3.1 信息收集与功能点枚举这是所有测试的第一步。你需要尽可能全面地了解目标应用。手动浏览以不同身份未登录用户、普通用户、高级用户如果有测试账号遍历整个应用使用浏览器开发者工具F12记录下所有的页面、功能、请求。爬虫辅助使用Burp Suite的Spider功能或OWASP ZAP的爬虫对目标进行自动化爬取发现更多隐藏的目录和参数。分析请求重点关注所有发送到服务器的HTTP请求GET, POST, PUT, DELETE等特别是那些包含以下元素的请求标识符参数id,uid,user_id,order_id,docid,fileid等。动作参数action,method,do,type等。角色/状态参数role,admin,isAdmin,status等。API接口现代应用大量使用/api/v1/这样的接口这些是测试的重中之重。3.2 水平越权漏洞挖掘实战步骤针对水平越权测试的核心思想是“替换资源标识观察响应”。测试用例准备你需要至少两个同一权限级别的测试账号例如UserA和UserB。关键功能定位找出所有涉及用户自身数据操作和查看的功能。例如查看个人资料、查看订单列表、查看消息、修改收货地址、上传/下载个人文件等。参数替换测试用UserA登录访问其个人资料页URL可能是https://target.com/profile?uid1001。在Burp Suite的Proxy或Repeater模块中捕获这个请求。将请求中的uid1001修改为uid1002假设是UserB的ID然后发送请求。观察响应成功如果返回了UserB的个人资料信息且HTTP状态码为200那么存在水平越权漏洞。失败但信息泄露如果返回403禁止访问或错误信息但错误信息中包含了UserB的用户名或部分信息如“无权查看用户[张三]的资料”这属于不安全的直接对象引用导致的信息泄露也是一个安全问题。成功但逻辑错误有时系统会返回成功200但数据依然是UserA的。这可能是因为后端从会话Session中获取了用户ID而忽略了请求参数。这说明参数设计冗余但未必是漏洞。需要进一步测试其他接口。扩大测试范围不要只测试URL参数。对POST请求的Body、JSON格式的数据、Cookie甚至HTTP头中的自定义字段都要进行同样的替换测试。自动化辅助对于ID可预测的情况如连续数字可以使用Burp Intruder进行批量枚举测试设置uid参数为载荷位置使用数字序列载荷快速测试大量ID的访问情况。实操心得测试时务必注意“上下文”。有些系统会使用全局唯一的GUID如550e8400-e29b-41d4-a716-446655440000作为标识符看似不可预测但如果这个GUID在其他地方被泄露例如通过UserA的某个公开分享链接那么攻击者依然可以利用它来尝试越权访问。因此即使ID不可预测只要它被用作访问资源的唯一凭证就必须在后端进行权限校验。3.3 垂直越权漏洞挖掘实战步骤垂直越权的测试核心是“低权限用户尝试访问高权限功能或修改权限属性”。权限矩阵梳理如果可能尽量获取或梳理出系统的角色权限矩阵。了解管理员、VIP用户、普通用户各自有哪些独特功能。隐藏功能探测目录/文件爆破使用DirBuster,gobuster或Burp Intruder对常见的管理员目录进行爆破如/admin/,/manage/,/backend/,/wp-admin/等。JS文件分析前端JavaScript代码中可能硬编码了管理员接口的URL。仔细审查加载的JS文件。源代码泄露检查是否存在.git目录泄露、.DS_Store文件、备份文件如www.zip,bak文件等这些可能包含路由信息。接口越权访问测试以普通用户身份登录。尝试直接访问管理员功能的前端页面如果知道URL。通常会被重定向或返回403。关键步骤使用浏览器开发者工具或Burp找到普通用户正常操作时发出的API请求。然后尝试将请求的路径Path修改为疑似管理员接口的路径。例如将POST /api/user/changeEmail改为POST /api/admin/deleteUser保持会话Cookie不变发送请求。观察响应。如果执行成功返回200及成功状态则存在严重的垂直越权。参数篡改权限提升测试找到用户修改自身信息的接口如更新个人资料。拦截请求寻找任何与权限、角色、等级相关的参数如role: user,isVIP: false。尝试修改这些参数的值如role: admin,isVIP: true然后提交请求。检查响应并重新登录或查看个人资料确认权限是否被提升。多阶段流程测试对于有工作流的操作用普通用户走完流程记录下所有请求和返回的令牌如订单号、申请ID。然后尝试用另一个低权限用户直接使用这些令牌访问流程中的其他阶段如查看详情、审核页面看是否能绕过权限检查。3.4 灰盒测试与代码审计视角如果你有源代码访问权限如内部测试、众测项目或开源软件挖掘效率将极大提升。搜索关键代码在代码库中全局搜索以下模式权限检查函数如checkPermission(),isAdmin(),hasRole()。查看这些函数是否在每一个需要权限的接口处都被调用。直接数据库查询搜索SQL查询语句中包含用户输入ID的地方如SELECT * FROM orders WHERE id orderId。检查其上方是否有类似if (order.user_id ! currentUserId)的校验。路由与控制器查看路由定义文件或控制器类确认访问特定URL路径是否需要特定的角色注解或装饰器如Spring的PreAuthorize(hasRole(ADMIN)) Django的permission_required。关注权限校验的缺失最危险的不是校验逻辑写错而是忘记写。审计时对每一个业务功能接口都要追踪其处理函数确认从请求开始到数据返回的整个链条中是否包含了针对当前用户和请求资源的权限校验语句。逻辑缺陷挖掘有时校验存在但有逻辑问题。例如// 错误示例先校验后再次从不可信源获取用户ID if (currentUser.isAdmin()) { int targetUserId Integer.parseInt(request.getParameter(uid)); // 这里仍然使用了用户输入的参数 userService.deleteUser(targetUserId); // 可能导致管理员误删或其他问题但这里更常见的是水平越权校验缺失 }正确的做法是对于涉及特定用户资源的操作即使当前用户是管理员也应从可信源如会话获取目标ID或对输入ID进行严格的归属校验。4. 漏洞挖掘工具链与技巧实录工欲善其事必先利其器。一套高效的工具体系能让你事半功倍。4.1 核心工具推荐与配置拦截代理 - Burp Suite Professional行业标准无可替代。Repeater用于手动修改重放请求Intruder用于参数爆破和枚举Scanner也能检测一些简单的越权问题。社区版 (Burp Suite Community) 功能受限但对于手动测试已足够。配置技巧在Project options - Sessions中配置好会话处理规则确保在测试不同用户时能自动管理Cookie方便切换上下文。浏览器开发者工具Chrome/Firefox的DevTools是轻量级测试的首选。Network标签页可以监控所有请求直接编辑并重放Replay XHR非常适合快速验证猜想。目录/文件爆破工具gobuster命令行工具速度快资源占用低。gobuster dir -u https://target.com -w /path/to/wordlist.txtDirBuster图形化界面历史悠久字典丰富。ffuf另一个非常快速灵活的Web模糊测试工具功能强大。ffuf -u https://target.com/FUZZ -w wordlist.txt浏览器插件AutorizeBurp Suite的插件用于自动测试越权。你可以配置一个低权限用户的会话然后让插件自动用这个会话去重放所有高权限用户访问的请求从而批量检测垂直越权极其高效。HackBar方便在浏览器地址栏快速构造和发送Payload。4.2 实战中的高级技巧与思维关注非主流HTTP方法不要只测试GET和POST。尝试使用PUT,PATCH,DELETE等方法访问资源接口有时权限校验只针对GET/POST忽略了其他方法。测试API版本如果遇到/api/v1/user/123尝试访问/api/v2/user/123或/api/user/123。不同版本的API可能存在不同的权限校验逻辑。参数污染Parameter Pollution尝试传递多个同名参数如uid1001uid1002。后端处理逻辑的差异可能导致校验被绕过。JSON参数修改对于JSON格式的请求除了修改值还可以尝试改变结构比如将{id: 1001}改为{id: 1001}类型转换问题或增加、删除字段看后端解析逻辑是否有缺陷。状态码与错误信息分析仔细分析所有非200响应。一个返回403的请求如果响应体里包含了“需要管理员权限”这确认了接口存在如果返回的是“用户未找到”则说明权限校验通过了但ID不存在。这些信息对理解后端逻辑至关重要。时间延迟探测Time-based Blind IDOR在极少数情况下越权访问可能不会在响应内容上体现差异但可能会因为数据库查询复杂度不同而导致响应时间有细微差别。这属于高级盲测技巧需要精确计时和大量请求。5. 经典案例复盘与排查记录理论结合实践下面复盘几个我遇到过的典型越权案例其中踩过的坑和收获的经验或许对你更有启发。5.1 案例一通过“分享链接”实现的大规模水平越权目标一个在线文档协作平台。测试过程用户A创建了一份私有文档系统生成了一个查看链接形如https://docs.com/view?doc_idabc123tokenxyz789。用户A将链接分享给用户B有权限。我测试员作为用户C拿到了这个链接。直觉告诉我token参数是临时授权凭证。我尝试直接访问https://docs.com/view?doc_idabc123去掉token。结果成功访问了用户A的私有文档漏洞原理后端校验逻辑存在严重缺陷。其伪代码如下def view_document(doc_id, tokenNone): doc Database.get_document(doc_id) if token is not None: # 如果提供了token验证token是否有效且未过期 if validate_token(token, doc_id): return render(doc) else: return error(无效链接) else: # 如果没有提供token则检查当前登录用户是否有权查看 if current_user.is_owner(doc) or current_user.is_collaborator(doc): return render(doc) else: return error(无权访问)问题在于当用户C未登录访问不带token的链接时current_user是None。is_owner和is_collaborator检查可能返回False或抛出异常但程序没有做好异常处理默认在检查失败后依然返回了文档内容或者校验逻辑存在漏洞直接允许了访问。修复建议权限校验必须放在最前面且默认拒绝。逻辑应为“获取文档 - 验证当前用户是否有权通过登录会话或有效token- 有权则返回否则一律拒绝”。5.2 案例二修改请求方法绕过的垂直越权目标一个内容管理系统CMS的后台。测试过程以普通编辑身份登录发现有一个“待审核文章列表”页面可以查看但无法审核按钮灰色。拦截查看文章详情的GET请求GET /admin/article/review?id100。将请求方法改为POST并添加一个actionapprove的参数重放请求。结果服务器返回了“审核成功”的JSON响应。漏洞原理后端路由配置或控制器方法可能使用了粗粒度的权限控制。// 类似Spring MVC的控制器 Controller RequestMapping(/admin/article) public class ArticleAdminController { GetMapping(/review) PreAuthorize(hasRole(EDITOR)) // 需要编辑角色才能GET访问 public String reviewPage(Long id, Model model) { ... } PostMapping(/review) // 这里缺少了 PreAuthorize(hasRole(ADMIN)) 注解 public ApiResult approveArticle(RequestParam Long id, RequestParam String action) { if (approve.equals(action)) { // 执行审核逻辑... return ApiResult.success(); } return ApiResult.error(); } }开发人员可能认为POST请求只会由前端审核按钮触发而按钮已对编辑隐藏所以安全。但攻击者可以轻易伪造POST请求。修复建议对每一个处理敏感操作的接口方法无论HTTP方法是什么都必须显式声明其所需的权限。遵循“默认拒绝”原则。5.3 案例三基于数字ID递增枚举的用户信息泄露这是一个非常经典且高发的IDOR案例在众多SRC安全应急响应中心的漏洞报告中屡见不鲜。目标一个用户中心接口。测试过程登录后访问“我的资料”页面捕获请求GET /api/v1/users/me/profile。响应中返回了完整的用户信息包括一个userId: 15001。尝试访问GET /api/v1/users/15001/profile返回我的信息。尝试访问GET /api/v1/users/15002/profile。结果返回了另一个用户的敏感信息邮箱、手机号、昵称等。漏洞原理后端接口设计采用了RESTful风格但实现时偷懒。/users/{id}/profile这个接口直接根据路径参数{id}查询数据库并返回没有校验{id}是否与当前登录用户的ID匹配。攻击者可以通过简单的脚本在短时间内枚举数万用户ID导致大规模数据泄露。排查技巧遇到RESTful API要重点测试资源ID是否可被遍历。使用Burp Intruder设置Sniper模式对ID参数使用“数字”载荷设置从1到10000步长为1观察哪些请求返回了200状态码和有效数据。这是一个低技术门槛但危害极高的测试点。6. 防御方案与安全开发建议挖漏洞是为了更好地修漏洞。作为开发者如何在编码阶段就杜绝越权问题实施统一的权限检查中间件/过滤器不要在每一个业务逻辑里分散地写权限检查代码。在请求进入业务控制器之前通过一个统一的拦截器根据“用户-角色-权限-资源”模型进行校验。这是最有效、最不容易遗漏的方式。使用不可预测的标识符避免使用自增整数作为资源ID。使用全局唯一的、随机的UUID或经过加密处理的令牌来引用资源。这能增加攻击者猜测的难度但请注意这不是真正的安全措施只是“通过隐蔽实现安全”后端校验依然必不可少。遵循“最小权限原则”和“默认拒绝原则”系统设计时每个用户、每个进程只能拥有完成其任务所必需的最小权限。任何未经明确允许的访问都应该被拒绝。对用户输入进行“所有权”校验任何时候只要操作涉及一个资源ID用户ID、订单号等后端必须验证当前登录的用户是否拥有这个资源的操作权限。验证逻辑应该基于会话中的用户标识而非客户端传来的任何参数。定期进行代码审计和渗透测试在开发流程中引入安全环节对代码进行人工或自动化审计。在上线前聘请专业的安全团队或使用自动化工具进行渗透测试主动发现越权等漏洞。完善的日志记录与监控记录所有敏感操作的日志包括操作者、时间、资源ID、操作结果等。通过监控异常访问模式如某个用户短时间内访问大量不同用户ID的资源可以及时发现潜在的攻击行为。水平与垂直越权漏洞看似简单却直指应用安全的核心——访问控制。它们的挖掘过程更像是一场与开发者思维定式的博弈。我个人的体会是测试时一定要摒弃“用户会按规矩操作”的假设时刻以攻击者的视角追问每一个参数“这个我能改吗改了会怎样系统真的检查了吗” 多问几个为什么漏洞往往就藏在这些问题的答案里。最后无论是挖掘还是修复记住一条黄金法则永远不要信任客户端传来的任何数据包括身份和权限声明。一切权限的裁决必须在服务端可靠地完成。
1. 项目概述理解越权漏洞的本质在Web安全测试的日常工作中越权漏洞Broken Access Control是出现频率极高、危害性极大的一类问题。它不像SQL注入或XSS那样需要复杂的构造很多时候仅仅是因为开发人员对用户权限的边界检查不够严格就为攻击者打开了通往敏感数据或功能的大门。简单来说越权就是“你做了你不该做的事”或者“你看了你不该看的东西”。根据权限跨越的方向我们通常将其分为水平越权和垂直越权。水平越权也叫作“平行越权”指的是攻击者能够访问或操作与其权限级别相同、但本应属于其他用户的资源。比如在一个社交网站中你通过修改URL中的用户ID参数成功看到了另一个普通用户的私密相册这就是典型水平越权。垂直越权则更为危险它指的是低权限用户如普通会员能够执行高权限用户如管理员才能进行的操作。例如一个论坛的普通用户通过某种方式访问到了后台管理员的删除帖子功能接口这就构成了垂直越权。为什么这类漏洞如此普遍根源在于“信任边界”的模糊。开发者在设计功能时往往默认用户会“规规矩矩”地使用前端界面而忽略了后端对每一个请求都必须进行严格的权限复核。前端隐藏了一个按钮不代表后端接口就安全了用户登录时验证了身份不代表后续每个操作都无需再次确认其权限。这种“默认安全”的思维正是越权漏洞滋生的温床。对于安全研究员、渗透测试工程师乃至开发人员而言透彻理解这两种越权的原理、掌握其挖掘方法是构建或评估一个健壮应用安全体系的必修课。2. 核心原理深度剖析权限模型的失效点要挖掘漏洞必须先理解漏洞产生的根源。越权漏洞的本质是应用程序的访问控制机制存在缺陷未能正确执行最小权限原则。让我们拆开来看这两种越权的技术原理。2.1 水平越权横向权限边界的缺失水平越权的核心问题在于应用程序在处理用户对数据对象的访问请求时没有验证“当前请求的用户是否是该数据对象的合法所有者”。其常见的技术实现漏洞点包括基于标识符的不安全直接对象引用IDOR这是最常见的形式。应用程序使用可预测的序列如递增的用户ID、订单号、文档ID作为资源标识。后端接口接收到如/api/user/profile?uid123的请求时直接根据uid123去数据库查询并返回数据而没有检查当前会话用户假设其uid是456是否有权限查看uid123的资料。攻击者只需遍历或猜测这些ID就能访问到大量其他用户的敏感信息。功能级水平越权某些功能本身并不直接关联特定数据对象但也不应该被所有同角色用户随意使用。例如一个“重置收货地址”的功能后端如果没有验证该地址是否属于当前用户攻击者就可能通过篡改请求中的地址ID参数将其他用户的地址修改或删除。多阶段流程中的权限泄露在一个多步骤的操作中如订单支付流程可能在第一步验证了权限但在后续的步骤如查看支付结果详情中仅凭一个步骤生成的令牌token或ID就返回数据而不再校验该令牌与当前用户的关联性。注意水平越权不一定需要“登录”。在某些设计不当的系统中即使未登录如果资源标识如一个分享链接的ID被猜解或泄露也可能直接访问到未授权的资源这有时也被归类为“未授权访问”但其原理与水平越权相通。2.2 垂直越权纵向权限校验的旁路垂直越权比水平越权危害更大因为它可能导致整个系统被控制。其原理在于应用程序未能区分不同权限等级用户的访问边界。常见漏洞模式包括隐藏接口与功能暴露管理员功能的前端界面可能对普通用户隐藏如通过CSS的display:none或直接不渲染但对应的后端API接口依然存在且可以被直接访问。如果该接口仅通过前端隐藏来“保护”而没有在后端进行角色或权限校验就会造成垂直越权。例如普通用户直接访问/admin/deleteUser.php可能就能执行删除操作。参数篡改与权限提升请求中可能包含标识用户角色的参数。例如在注册或修改用户信息的请求中有一个roleuser的参数。如果后端完全信任这个来自客户端可能被篡改的参数攻击者将其改为roleadmin并提交就可能直接将自己提升为管理员。不安全的权限继承与配置在复杂的系统或使用某些框架时可能存在默认配置不安全的情况。例如某个Web框架的路由配置中默认所有认证用户都可以访问某个管理前缀的路由而开发人员忘记添加额外的角色拦截器。平行权限与交叉越权这是一种特殊场景。系统可能存在多个平行的权限角色如“教师”和“学生”。一个“学生”角色用户通过漏洞访问到了本该只有“教师”角色才能使用的功能如发布作业这也属于垂直越权因为这是在两个不同权限等级之间的跨越。理解这些原理后我们就能像攻击者一样思考系统在哪里区分用户在哪里校验权限这些校验是否可以被绕过这些点就是我们的重点测试目标。3. 实战漏洞挖掘方法论从黑盒到灰盒掌握了原理接下来就是如何在实际的Web应用中发现这些漏洞。我个人的经验是采用一种从“黑盒”到“灰盒”的渐进式挖掘思路效率最高。3.1 信息收集与功能点枚举这是所有测试的第一步。你需要尽可能全面地了解目标应用。手动浏览以不同身份未登录用户、普通用户、高级用户如果有测试账号遍历整个应用使用浏览器开发者工具F12记录下所有的页面、功能、请求。爬虫辅助使用Burp Suite的Spider功能或OWASP ZAP的爬虫对目标进行自动化爬取发现更多隐藏的目录和参数。分析请求重点关注所有发送到服务器的HTTP请求GET, POST, PUT, DELETE等特别是那些包含以下元素的请求标识符参数id,uid,user_id,order_id,docid,fileid等。动作参数action,method,do,type等。角色/状态参数role,admin,isAdmin,status等。API接口现代应用大量使用/api/v1/这样的接口这些是测试的重中之重。3.2 水平越权漏洞挖掘实战步骤针对水平越权测试的核心思想是“替换资源标识观察响应”。测试用例准备你需要至少两个同一权限级别的测试账号例如UserA和UserB。关键功能定位找出所有涉及用户自身数据操作和查看的功能。例如查看个人资料、查看订单列表、查看消息、修改收货地址、上传/下载个人文件等。参数替换测试用UserA登录访问其个人资料页URL可能是https://target.com/profile?uid1001。在Burp Suite的Proxy或Repeater模块中捕获这个请求。将请求中的uid1001修改为uid1002假设是UserB的ID然后发送请求。观察响应成功如果返回了UserB的个人资料信息且HTTP状态码为200那么存在水平越权漏洞。失败但信息泄露如果返回403禁止访问或错误信息但错误信息中包含了UserB的用户名或部分信息如“无权查看用户[张三]的资料”这属于不安全的直接对象引用导致的信息泄露也是一个安全问题。成功但逻辑错误有时系统会返回成功200但数据依然是UserA的。这可能是因为后端从会话Session中获取了用户ID而忽略了请求参数。这说明参数设计冗余但未必是漏洞。需要进一步测试其他接口。扩大测试范围不要只测试URL参数。对POST请求的Body、JSON格式的数据、Cookie甚至HTTP头中的自定义字段都要进行同样的替换测试。自动化辅助对于ID可预测的情况如连续数字可以使用Burp Intruder进行批量枚举测试设置uid参数为载荷位置使用数字序列载荷快速测试大量ID的访问情况。实操心得测试时务必注意“上下文”。有些系统会使用全局唯一的GUID如550e8400-e29b-41d4-a716-446655440000作为标识符看似不可预测但如果这个GUID在其他地方被泄露例如通过UserA的某个公开分享链接那么攻击者依然可以利用它来尝试越权访问。因此即使ID不可预测只要它被用作访问资源的唯一凭证就必须在后端进行权限校验。3.3 垂直越权漏洞挖掘实战步骤垂直越权的测试核心是“低权限用户尝试访问高权限功能或修改权限属性”。权限矩阵梳理如果可能尽量获取或梳理出系统的角色权限矩阵。了解管理员、VIP用户、普通用户各自有哪些独特功能。隐藏功能探测目录/文件爆破使用DirBuster,gobuster或Burp Intruder对常见的管理员目录进行爆破如/admin/,/manage/,/backend/,/wp-admin/等。JS文件分析前端JavaScript代码中可能硬编码了管理员接口的URL。仔细审查加载的JS文件。源代码泄露检查是否存在.git目录泄露、.DS_Store文件、备份文件如www.zip,bak文件等这些可能包含路由信息。接口越权访问测试以普通用户身份登录。尝试直接访问管理员功能的前端页面如果知道URL。通常会被重定向或返回403。关键步骤使用浏览器开发者工具或Burp找到普通用户正常操作时发出的API请求。然后尝试将请求的路径Path修改为疑似管理员接口的路径。例如将POST /api/user/changeEmail改为POST /api/admin/deleteUser保持会话Cookie不变发送请求。观察响应。如果执行成功返回200及成功状态则存在严重的垂直越权。参数篡改权限提升测试找到用户修改自身信息的接口如更新个人资料。拦截请求寻找任何与权限、角色、等级相关的参数如role: user,isVIP: false。尝试修改这些参数的值如role: admin,isVIP: true然后提交请求。检查响应并重新登录或查看个人资料确认权限是否被提升。多阶段流程测试对于有工作流的操作用普通用户走完流程记录下所有请求和返回的令牌如订单号、申请ID。然后尝试用另一个低权限用户直接使用这些令牌访问流程中的其他阶段如查看详情、审核页面看是否能绕过权限检查。3.4 灰盒测试与代码审计视角如果你有源代码访问权限如内部测试、众测项目或开源软件挖掘效率将极大提升。搜索关键代码在代码库中全局搜索以下模式权限检查函数如checkPermission(),isAdmin(),hasRole()。查看这些函数是否在每一个需要权限的接口处都被调用。直接数据库查询搜索SQL查询语句中包含用户输入ID的地方如SELECT * FROM orders WHERE id orderId。检查其上方是否有类似if (order.user_id ! currentUserId)的校验。路由与控制器查看路由定义文件或控制器类确认访问特定URL路径是否需要特定的角色注解或装饰器如Spring的PreAuthorize(hasRole(ADMIN)) Django的permission_required。关注权限校验的缺失最危险的不是校验逻辑写错而是忘记写。审计时对每一个业务功能接口都要追踪其处理函数确认从请求开始到数据返回的整个链条中是否包含了针对当前用户和请求资源的权限校验语句。逻辑缺陷挖掘有时校验存在但有逻辑问题。例如// 错误示例先校验后再次从不可信源获取用户ID if (currentUser.isAdmin()) { int targetUserId Integer.parseInt(request.getParameter(uid)); // 这里仍然使用了用户输入的参数 userService.deleteUser(targetUserId); // 可能导致管理员误删或其他问题但这里更常见的是水平越权校验缺失 }正确的做法是对于涉及特定用户资源的操作即使当前用户是管理员也应从可信源如会话获取目标ID或对输入ID进行严格的归属校验。4. 漏洞挖掘工具链与技巧实录工欲善其事必先利其器。一套高效的工具体系能让你事半功倍。4.1 核心工具推荐与配置拦截代理 - Burp Suite Professional行业标准无可替代。Repeater用于手动修改重放请求Intruder用于参数爆破和枚举Scanner也能检测一些简单的越权问题。社区版 (Burp Suite Community) 功能受限但对于手动测试已足够。配置技巧在Project options - Sessions中配置好会话处理规则确保在测试不同用户时能自动管理Cookie方便切换上下文。浏览器开发者工具Chrome/Firefox的DevTools是轻量级测试的首选。Network标签页可以监控所有请求直接编辑并重放Replay XHR非常适合快速验证猜想。目录/文件爆破工具gobuster命令行工具速度快资源占用低。gobuster dir -u https://target.com -w /path/to/wordlist.txtDirBuster图形化界面历史悠久字典丰富。ffuf另一个非常快速灵活的Web模糊测试工具功能强大。ffuf -u https://target.com/FUZZ -w wordlist.txt浏览器插件AutorizeBurp Suite的插件用于自动测试越权。你可以配置一个低权限用户的会话然后让插件自动用这个会话去重放所有高权限用户访问的请求从而批量检测垂直越权极其高效。HackBar方便在浏览器地址栏快速构造和发送Payload。4.2 实战中的高级技巧与思维关注非主流HTTP方法不要只测试GET和POST。尝试使用PUT,PATCH,DELETE等方法访问资源接口有时权限校验只针对GET/POST忽略了其他方法。测试API版本如果遇到/api/v1/user/123尝试访问/api/v2/user/123或/api/user/123。不同版本的API可能存在不同的权限校验逻辑。参数污染Parameter Pollution尝试传递多个同名参数如uid1001uid1002。后端处理逻辑的差异可能导致校验被绕过。JSON参数修改对于JSON格式的请求除了修改值还可以尝试改变结构比如将{id: 1001}改为{id: 1001}类型转换问题或增加、删除字段看后端解析逻辑是否有缺陷。状态码与错误信息分析仔细分析所有非200响应。一个返回403的请求如果响应体里包含了“需要管理员权限”这确认了接口存在如果返回的是“用户未找到”则说明权限校验通过了但ID不存在。这些信息对理解后端逻辑至关重要。时间延迟探测Time-based Blind IDOR在极少数情况下越权访问可能不会在响应内容上体现差异但可能会因为数据库查询复杂度不同而导致响应时间有细微差别。这属于高级盲测技巧需要精确计时和大量请求。5. 经典案例复盘与排查记录理论结合实践下面复盘几个我遇到过的典型越权案例其中踩过的坑和收获的经验或许对你更有启发。5.1 案例一通过“分享链接”实现的大规模水平越权目标一个在线文档协作平台。测试过程用户A创建了一份私有文档系统生成了一个查看链接形如https://docs.com/view?doc_idabc123tokenxyz789。用户A将链接分享给用户B有权限。我测试员作为用户C拿到了这个链接。直觉告诉我token参数是临时授权凭证。我尝试直接访问https://docs.com/view?doc_idabc123去掉token。结果成功访问了用户A的私有文档漏洞原理后端校验逻辑存在严重缺陷。其伪代码如下def view_document(doc_id, tokenNone): doc Database.get_document(doc_id) if token is not None: # 如果提供了token验证token是否有效且未过期 if validate_token(token, doc_id): return render(doc) else: return error(无效链接) else: # 如果没有提供token则检查当前登录用户是否有权查看 if current_user.is_owner(doc) or current_user.is_collaborator(doc): return render(doc) else: return error(无权访问)问题在于当用户C未登录访问不带token的链接时current_user是None。is_owner和is_collaborator检查可能返回False或抛出异常但程序没有做好异常处理默认在检查失败后依然返回了文档内容或者校验逻辑存在漏洞直接允许了访问。修复建议权限校验必须放在最前面且默认拒绝。逻辑应为“获取文档 - 验证当前用户是否有权通过登录会话或有效token- 有权则返回否则一律拒绝”。5.2 案例二修改请求方法绕过的垂直越权目标一个内容管理系统CMS的后台。测试过程以普通编辑身份登录发现有一个“待审核文章列表”页面可以查看但无法审核按钮灰色。拦截查看文章详情的GET请求GET /admin/article/review?id100。将请求方法改为POST并添加一个actionapprove的参数重放请求。结果服务器返回了“审核成功”的JSON响应。漏洞原理后端路由配置或控制器方法可能使用了粗粒度的权限控制。// 类似Spring MVC的控制器 Controller RequestMapping(/admin/article) public class ArticleAdminController { GetMapping(/review) PreAuthorize(hasRole(EDITOR)) // 需要编辑角色才能GET访问 public String reviewPage(Long id, Model model) { ... } PostMapping(/review) // 这里缺少了 PreAuthorize(hasRole(ADMIN)) 注解 public ApiResult approveArticle(RequestParam Long id, RequestParam String action) { if (approve.equals(action)) { // 执行审核逻辑... return ApiResult.success(); } return ApiResult.error(); } }开发人员可能认为POST请求只会由前端审核按钮触发而按钮已对编辑隐藏所以安全。但攻击者可以轻易伪造POST请求。修复建议对每一个处理敏感操作的接口方法无论HTTP方法是什么都必须显式声明其所需的权限。遵循“默认拒绝”原则。5.3 案例三基于数字ID递增枚举的用户信息泄露这是一个非常经典且高发的IDOR案例在众多SRC安全应急响应中心的漏洞报告中屡见不鲜。目标一个用户中心接口。测试过程登录后访问“我的资料”页面捕获请求GET /api/v1/users/me/profile。响应中返回了完整的用户信息包括一个userId: 15001。尝试访问GET /api/v1/users/15001/profile返回我的信息。尝试访问GET /api/v1/users/15002/profile。结果返回了另一个用户的敏感信息邮箱、手机号、昵称等。漏洞原理后端接口设计采用了RESTful风格但实现时偷懒。/users/{id}/profile这个接口直接根据路径参数{id}查询数据库并返回没有校验{id}是否与当前登录用户的ID匹配。攻击者可以通过简单的脚本在短时间内枚举数万用户ID导致大规模数据泄露。排查技巧遇到RESTful API要重点测试资源ID是否可被遍历。使用Burp Intruder设置Sniper模式对ID参数使用“数字”载荷设置从1到10000步长为1观察哪些请求返回了200状态码和有效数据。这是一个低技术门槛但危害极高的测试点。6. 防御方案与安全开发建议挖漏洞是为了更好地修漏洞。作为开发者如何在编码阶段就杜绝越权问题实施统一的权限检查中间件/过滤器不要在每一个业务逻辑里分散地写权限检查代码。在请求进入业务控制器之前通过一个统一的拦截器根据“用户-角色-权限-资源”模型进行校验。这是最有效、最不容易遗漏的方式。使用不可预测的标识符避免使用自增整数作为资源ID。使用全局唯一的、随机的UUID或经过加密处理的令牌来引用资源。这能增加攻击者猜测的难度但请注意这不是真正的安全措施只是“通过隐蔽实现安全”后端校验依然必不可少。遵循“最小权限原则”和“默认拒绝原则”系统设计时每个用户、每个进程只能拥有完成其任务所必需的最小权限。任何未经明确允许的访问都应该被拒绝。对用户输入进行“所有权”校验任何时候只要操作涉及一个资源ID用户ID、订单号等后端必须验证当前登录的用户是否拥有这个资源的操作权限。验证逻辑应该基于会话中的用户标识而非客户端传来的任何参数。定期进行代码审计和渗透测试在开发流程中引入安全环节对代码进行人工或自动化审计。在上线前聘请专业的安全团队或使用自动化工具进行渗透测试主动发现越权等漏洞。完善的日志记录与监控记录所有敏感操作的日志包括操作者、时间、资源ID、操作结果等。通过监控异常访问模式如某个用户短时间内访问大量不同用户ID的资源可以及时发现潜在的攻击行为。水平与垂直越权漏洞看似简单却直指应用安全的核心——访问控制。它们的挖掘过程更像是一场与开发者思维定式的博弈。我个人的体会是测试时一定要摒弃“用户会按规矩操作”的假设时刻以攻击者的视角追问每一个参数“这个我能改吗改了会怎样系统真的检查了吗” 多问几个为什么漏洞往往就藏在这些问题的答案里。最后无论是挖掘还是修复记住一条黄金法则永远不要信任客户端传来的任何数据包括身份和权限声明。一切权限的裁决必须在服务端可靠地完成。
