1. 项目概述为什么我们需要自动化越权检测在Web应用安全测试的日常工作中越权漏洞包括水平越权和垂直越权是出现频率极高、危害性也极大的一个类别。想象一下你正在测试一个电商平台你用自己的账号A登录后发现通过修改请求中的用户ID参数竟然能直接访问到账号B的订单详情、收货地址甚至修改其密码。这种“用一个账号操作所有数据”的漏洞就是典型的水平越权。而垂直越权则更危险比如一个普通用户通过某种方式获取到了管理员的接口权限从而能进行用户封禁、数据导出等高危操作。传统的手动测试方法效率低下且容易遗漏。测试人员需要反复登录不同账号截取请求包手动替换Cookie、Token或ID参数然后逐个发送请求并观察响应。这个过程枯燥、重复并且当测试点成百上千时人力几乎无法覆盖。这就是自动化介入的最佳场景。Burpsuite的Intruder模块作为其“入侵”功能的核心本质是一个高度可定制的自动化请求发送器。它允许我们定义好一个请求模板标记出需要“爆破”或“遍历”的位置我们称之为攻击载荷位置然后载入一个字典或序列由工具自动替换这些位置的内容并发送大量请求。将Intruder模块与Cookie替换相结合就形成了一套高效的自动化越权检测流水线我们只需要准备好目标用户的身份凭证Cookie列表然后让Intruder自动将这些Cookie填入请求中批量访问那些本应受权限控制的接口通过分析响应差异快速定位漏洞。这套方法的价值在于它将安全测试人员从机械的重复劳动中解放出来专注于更核心的逻辑分析与漏洞挖掘。无论是审计一个拥有大量功能模块的新系统还是对现有系统进行周期性的回归测试自动化越权检测都能显著提升覆盖率和效率。接下来我将拆解整个流程的设计思路、实操细节以及我踩过的那些坑。2. 核心思路与Intruder模块深度解析2.1 自动化越权检测的核心逻辑自动化越权检测的底层逻辑并不复杂其核心在于“权限旁路验证”。我们不是去正向分析系统的权限模型而是通过“冒用身份”的方式去试探系统对身份校验的边界是否牢固。整个流程可以抽象为以下几步身份收集获取一批有效的用户会话标识最常见的就是Cookie如sessionid,token有时也可能是Authorization头中的JWT。请求捕获使用Burpsuite代理捕获一个在已登录状态下发起的、指向敏感功能或数据的请求。这个请求本身是合法的。变量标记在Burpsuite中将这个合法请求发送到Intruder模块并将其中的身份标识如Cookie头标记为攻击载荷位置。载荷配置将步骤1中收集到的其他用户Cookie作为攻击载荷Payload载入。批量测试启动Intruder攻击它会自动用载荷列表中的每一个Cookie替换原请求中的Cookie然后发送请求。结果分析观察每个请求的响应状态码、长度、内容。如果某个使用其他用户Cookie的请求返回了与原请求使用自己Cookie相同或相似的成功响应如200状态码且包含敏感数据则极有可能存在越权漏洞。这里的关键在于“响应比对”。Intruder提供了强大的结果分析功能如“状态码”、“响应长度”、“响应内容差异”等帮助我们快速筛选出异常请求。2.2 Intruder模块的四种攻击模式详解Intruder提供了四种攻击模式适用于不同场景的越权测试Sniper狙击手模式这是最常用、也是本次Cookie替换的核心模式。它使用单一的Payload集合依次替换请求中所有被标记的位置。但关键点在于它每次攻击只替换一个标记位置。如果我们只标记了Cookie头这一个位置那么Sniper模式会逐个使用Payload列表中的Cookie进行替换并发送请求这完美契合了“用不同用户Cookie测试同一个接口”的需求。Battering ram攻城锤模式同样使用一个Payload集合但它会用同一个Payload值同时替换所有被标记的位置。这在越权检测中用途有限除非你的请求中有多个位置需要同步替换为同一个值例如Cookie头和某个Body参数都需要替换为同一用户ID。Pitchfork草叉模式这是功能强大的模式它允许你为每一个标记的位置配置独立的Payload集合。攻击时它会从每个Payload集合中按顺序取一个值组合后发送请求。这非常适合测试“用户名和密码一一对应”的爆破或者需要同时替换“Cookie”和“URL中的用户ID”两个关联参数的场景。例如位置1放Cookie列表位置2放对应的用户ID列表可以测试系统是否同时校验了两者。Cluster bomb集束炸弹模式最暴力的模式。它为每个标记位置配置独立的Payload集合然后进行笛卡尔积式的遍历即每个位置的所有值与其他位置的所有值进行组合。这会生成巨量的请求Payload数量相乘。在越权测试中慎用通常用于当你不确定哪个参数是权限校验关键时进行穷举测试但极易触发风控。实操心得对于单纯的Cookie替换越权检测99%的情况使用Sniper模式就够了。清晰、直接、高效。只有在需要关联测试多个参数时才考虑Pitchfork模式。切勿盲目使用Cluster bomb除非你明确知道自己在做什么并且目标系统没有请求频率限制。2.3 Payload类型选择与处理Intruder支持多种Payload类型对于Cookie替换我们主要用到Simple list简单列表最常用的类型。直接将准备好的Cookie列表每行一个粘贴进去即可。Runtime file运行时文件如果Cookie列表很大可以保存为.txt文件然后在这里指定文件路径。Intruder会按需读取避免内存占用过高。Custom iterator自定义迭代器用于构建复杂的Payload比如将固定的Cookie前缀与变化的Session ID组合。如何准备Cookie列表这是实战中的第一个难点。Cookie不能凭空产生通常来自手动注册在测试环境中批量注册测试账号然后通过脚本或手动登录抓取Cookie。流量记录在测试初期将Burpsuite的代理历史Proxy history中所有包含Set-Cookie响应的请求筛选出来提取Cookie值。可以结合Burpsuite的“Target”站点地图功能查看不同用户会话下的请求。从其他工具导入例如使用Selenium自动化脚本登录一批账号后将获取到的Cookie导出为特定格式。漏洞利用如果存在信息泄露漏洞如用户列表泄露可能结合其他漏洞获取会话但这已超出单纯检测范畴。注意事项确保你使用的Cookie是有效且未过期的。无效的Cookie会导致请求返回401/403或跳转登录页面干扰判断。在导入Intruder前最好先用Burp的Repeater模块随机抽检几个Cookie的有效性。3. 实战演练从抓包到批量检测的完整流程3.1 环境准备与测试目标定义假设我们有一个名为vuln-app.com的测试靶场其中有一个API接口GET /api/v1/user/orders用于获取当前登录用户的订单列表。正常逻辑是用户A登录后访问此接口只能看到A自己的订单。我们的目标是检测该系统是否存在水平越权漏洞即用户A能否通过替换Cookie访问到用户B、用户C等的订单数据。前置步骤确保Burpsuite代理已正确配置浏览器流量经过Burp。准备至少两个测试账号user_a(密码: pass_a) 和user_b(密码: pass_b)。明确测试的接口及其正常请求格式。3.2 步骤一捕获基准请求与Cookie提取首先我们用user_a登录系统。在Burpsuite中开启代理拦截Intercept is on。在浏览器中访问https://vuln-app.com/api/v1/user/orders。在Burp的Proxy - Intercept标签页中你会看到被拦截的GET请求。将其发送到RepeaterCtrlR以便后续操作。同时也右键点击该请求选择 “Send to Intruder”。这时Intruder模块的Target和Positions标签页会自动填充。现在我们来获取user_a和user_b的Cookie。在Repeater中发送user_a的请求。查看响应确认返回了user_a的订单数据状态码200有数据体。这个请求和响应将作为我们的“基准”。记录下user_a请求头中的Cookie值例如sessioneyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...在浏览器中退出user_a登录user_b。重复步骤1-2捕获user_b访问同一接口的请求并记录其Cookie值。你会发现user_b的Cookie与user_a的不同。至此我们拥有了一个基准请求user_a的。两个有效的Cookiecookie_a(来自user_a) 和cookie_b(来自user_b)。3.3 步骤二配置Intruder进行Cookie替换切换到Intruder模块的“Positions”标签页。攻击模式选择在顶部下拉菜单中选择“Sniper”。清除默认标记点击右侧的“Clear §”按钮清空所有Intruder自动添加的载荷位置标记§。手动标记Cookie在请求头中找到Cookie:这一行。用鼠标选中整个Cookie的值不包括Cookie:这个词本身然后点击“Add §”按钮。你会看到选中的内容被一对§符号包围例如Cookie: §sessioneyJhbGci...§。这表示这里将被替换。关键技巧有时Cookie很长确保你标记的是完整的值包括可能存在的多个键值对如sessionxxx; user_tokenyyy。最稳妥的方法是先点击“Clear §”然后只在你需要替换的Cookie值部分添加标记。接下来切换到“Payloads”标签页。Payload类型确认是“Simple list”。载入Payload在下方的大文本框中我们将输入用于替换的Cookie列表。第一行我们放入user_b的Cookie。为了对比我们也可以把user_a自己的Cookie加进去作为对照组。例如sessioneyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... (这是user_b的cookie) sessioneyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... (这是user_a的cookie用于验证正常情况) invalid_cookie_value (这是一个明显错误的Cookie用于验证失效情况)这里我们添加了三行攻击载荷user_b、正常对照user_a、无效对照。3.4 步骤三攻击执行与精细化结果分析在开始攻击前建议先进行一些配置以便更好地分析结果。 切换到“Options”标签页这里有很多实用设置请求引擎可以设置请求线程数Number of threads、重试次数。对于内部测试线程数可以设高一些如10-20以加快速度对生产环境务必调低如3-5避免造成压力。Grep - Match这是一个神器。我们可以设置它从响应中提取特定字符串用于快速判断。例如如果我们知道user_b的订单里包含一个特殊商品名“TestProduct_B”我们可以在“Grep - Match”部分添加这个字符串。这样在结果表中如果某个请求的响应里包含了“TestProduct_B”就会被打勾标记一目了然。Grep - Extract可以提取响应中的某一段内容通过指定前缀和后缀便于对比。配置好后点击顶部菜单的“Start attack”。 Intruder会弹出一个新窗口开始自动发送请求。你会看到三个请求依次被发送使用user_b的Cookie访问/api/v1/user/orders。使用user_a的Cookie访问这是我们的原请求应成功。使用一个无效Cookie访问应失败。分析结果列攻击完成后结果窗口的表格至关重要主要关注这几列Request请求序号。Payload使用的Payload值Cookie。StatusHTTP状态码。如果user_b的请求也是200这就是一个强警报。Length响应体长度。对比user_a和user_b请求的Length。如果长度相同或非常接近而两者返回的数据理应不同订单数、订单号不同这很可能意味着服务端没有根据Cookie区分用户直接返回了相同的数据可能是缓存或默认数据。长度差异是发现越权的重要线索。Time响应时间通常用于判断是否存在延时注入等此处次要。Grep Match如果你设置了Grep Match这里会显示是否匹配。现在我们来解读最可能出现的几种情况请求 (Payload)状态码响应长度可能原因与结论user_b的Cookie200与user_a不同高危存在水平越权。系统接受了user_b的Cookie并返回了user_b的订单数据。这意味着任何用户只要获得他人的Cookie就能直接获取其数据。user_b的Cookie200与user_a相同/极近可疑需要人工复核。可能返回了错误的数据如user_a的数据也可能系统返回了空数据或默认数据但状态码是200。必须点开响应查看具体内容。user_b的Cookie403 / 401较小安全。系统正确拒绝了非本人的访问请求。user_b的Cookie302(重定向)较小通常重定向到登录页表示Cookie无效或会话过期。但如果重定向到一个“错误页面”而非登录页仍需查看具体Location。无效Cookie401/403/302小符合预期系统鉴权有效。在我们的假设漏洞场景中使用user_b的Cookie请求后我们得到了状态码200并且响应内容里确实包含了user_b的订单信息可以通过Grep Match或手动查看响应确认。这就坐实了水平越权漏洞的存在。4. 高级技巧与复杂场景应对4.1 处理动态Token与签名Cookie现代应用常使用JWT等Token机制或对Cookie进行签名、加密。这给自动化测试带来了挑战因为Cookie可能每次登录都变或者含有时间戳、签名信息直接替换可能失效。应对策略会话保持在获取Cookie后尽快开始测试避免会话过期。可以在Intruder的“Options” - “Request Headers”中取消勾选“Update Content-Length”和“Set Connection: close”但这并非总是有效。关联参数处理有时权限校验不仅依赖Cookie还依赖Body或URL中的某个ID参数如user_id123。你需要使用Pitchfork模式。在Positions中标记两个位置一个是Cookie头另一个是user_id参数。在Payloads标签页为第一个位置Cookie设置Payload set 1载入[cookie_a, cookie_b]。为第二个位置user_id设置Payload set 2载入对应的[id_a, id_b]。Intruder会使用(cookie_a, id_a)和(cookie_b, id_b)的组合发送请求。这用于测试系统是否校验了Cookie与ID的归属关系。使用宏Macro自动获取新Cookie对于会话时间很短的应用可以配置Burpsuite的Session Handling Rules。创建一个宏Macro记录登录请求和提取Cookie的步骤。然后创建一条规则在检测到会话无效时如响应包含“login”自动执行该宏获取新Cookie并更新到后续请求中。这实现了全自动的会话维持非常适合长时间自动化扫描。4.2 利用Grep功能进行高效结果过滤当测试大量接口和Cookie时结果列表会非常庞大。Grep功能是快速定位问题的关键。Grep - Match匹配不仅用于匹配目标用户数据还可以用于匹配错误信息。例如添加“权限不足”、“Access denied”、“不是你的”等字符串。在结果中如果本应失败的请求没有出现这些匹配项而状态码又是200那这个请求就非常可疑。Grep - Extract提取对于返回JSON或HTML的接口可以提取关键字段进行对比。例如提取JSON中的userName或orderCount字段。在结果表中你可以直接排序或对比这些提取出的值快速发现不同Cookie返回了相同用户名或订单数量的异常情况。4.3 集成与批量测试针对站点地图Site Map进行扫描手动一个个接口发送到Intruder效率太低。我们可以结合Burpsuite的爬虫Spider或主动扫描Active Scan功能先构建出目标站点的地图。以某个低权限用户如user_a身份浏览网站让Burp爬虫爬取所有可访问的链接。在Target - Site Map中你会看到该用户权限下的所有请求。全选这些请求或选中某个目录下的请求右键选择“Scan” - “Audit items”。但这里我们不用主动扫描器而是用它的“生成测试用例”的思路。更高效的方法是使用Burpsuite的“Copy URLs in this branch”功能将URL列表导出。然后你可以编写一个简单的Python脚本读取这些URL为每一个URL构造HTTP请求并将请求通过Burp的REST API如果使用Pro版或手动方式发送到Intruder。但更直接的方法是使用Burp的“Logger”插件或自定义插件自动将符合特定条件如包含/api/,/admin/路径的请求发送到Intruder队列。这实现了半自动化的漏洞探测你以普通用户身份浏览一遍网站工具自动收集所有请求点然后自动用高权限或其他用户的Cookie去重放这些请求批量检测越权。5. 常见问题、排查技巧与防御建议5.1 实战中常见问题与解决方案问题现象可能原因排查与解决思路所有使用其他Cookie的请求都返回403/4011. 系统鉴权健全无漏洞。2. Cookie格式错误或已过期。3. 请求缺少其他必要头如X-CSRF-Token,Referer。1. 在Repeater中用原Cookie确认接口可用。2. 检查Cookie值是否完整包含所有键值对。3. 对比原请求与Intruder请求的原始数据Raw看是否在发送过程中丢失了其他头。在Intruder的“Request Headers”区域确保相关头被保留。状态码都是200但长度完全相同1. 接口可能返回了空数据或默认数据如[]。2. 服务端有缓存返回了第一个请求的缓存结果。3. 真正的响应差异在内容深处长度巧合相同。1.必须查看响应内容长度只是初步筛选工具。2. 在Intruder的“Options”中添加“Grep - Extract”提取核心数据字段进行对比。3. 在请求中添加随机参数如_t1646382923绕过缓存。请求速度很慢或大量失败1. Intruder线程数设置过高触发目标服务器限流或防火墙。2. 网络不稳定。3. 目标应用处理慢。1. 降低“Options”中的线程数如降到3-5。2. 增加“Retry on failure”的重试次数和间隔。3. 分批次测试不要一次性发送过多请求。无法标记Cookie位置Cookie值可能被Burpsuite的某些扩展或默认规则修改了。1. 在Proxy - HTTP history中找到原始请求右键“Send to Intruder”。2. 检查是否安装了可能修改请求的插件临时禁用试试。测试时自己的会话被踢下线系统可能设置了单点登录或会话互斥机制新的有效登录会使旧会话失效。1. 使用不同的浏览器或无痕模式为每个测试账号建立会话。2. 在独立的虚拟机或容器环境中为每个账号运行单独的测试实例。5.2 给开发者的防御建议从攻击者的视角反过来可以给开发者提出更落地的修复建议权限校验与业务逻辑分离不要在每一个控制器函数里散落着if (currentUser.id ! targetUserId)这样的代码。应该设计统一的权限校验层中间件、拦截器、AOP在请求进入业务逻辑前根据会话信息从Token/Cookie解析出的用户ID和请求资源ID进行强制校验。使用不可预测的标识符避免使用自增整数1,2,3...作为用户ID、订单ID等在URL或参数中暴露。改用UUID或经过编码的随机字符串增加攻击者猜测和遍历的难度。最小化会话信息Cookie或Token中不应包含可以直接用于查询的敏感ID。服务端应通过签名验证Token后从自己的存储如数据库、缓存中查询出对应的用户完整信息。关键操作二次鉴权对于删除、修改密码、转账等高危操作除了会话Cookie应要求用户再次输入密码或进行MFA验证。完善的日志与监控记录所有敏感接口的访问日志包括访问的用户ID、请求的资源ID、时间戳。设置告警规则当同一会话短时间内访问大量不同用户的资源时及时发出警报。5.3 个人心得与延伸思考自动化越权检测只是安全测试中的一个环节。Intruder模块的强大之处在于其灵活性它本质上是一个HTTP请求编排器。除了替换Cookie你还可以用它来测试IDOR不安全的直接对象引用标记URL中的/api/user/§123§/profile的ID部分用数字字典进行遍历。测试参数污染对同一个参数名标记多个位置测试后端处理逻辑。模糊测试Fuzzing使用预定义的Fuzz字典对参数值进行畸形输入测试。然而工具再强大也无法替代测试人员的思维。自动化可以帮助我们快速完成“广度”覆盖但漏洞的深度挖掘、业务逻辑的理解、以及那些隐藏在复杂交互中的权限问题依然需要依靠测试人员对业务的理解和手工测试的经验。我的习惯是先用自动化跑一遍筛选出可疑点然后针对这些点结合业务场景进行深入的手工测试和代码审计如果可能这样才能最大限度地保证测试质量。最后始终牢记测试的道德与法律边界。所有的测试都必须在获得明确授权的环境中进行。未经授权的测试无论目的如何都是非法的。