当前位置：首页 > news >正文

Burpsuite Intruder自动化越权测试：Cookie替换实战指南

news 2026/7/3 0:05:31

1. 项目概述：为什么越权测试必须自动化？

做Web安全测试的同行都知道，越权漏洞（包括水平越权和垂直越权）是业务逻辑漏洞里的“常青树”。它不像SQL注入或XSS那样有明确的攻击载荷，其核心在于权限校验的缺失或绕过。手动测试时，我们通常会登录两个不同权限的账号，然后尝试用A账号的凭证（比如Cookie）去访问B账号的接口或数据。这个过程繁琐、重复，而且容易出错，尤其是在测试包含大量用户ID、订单ID等参数的接口时。

这就是为什么我们需要Burpsuite的Intruder模块。它本质上是一个高度可定制的自动化请求发送器，能够批量替换请求中的特定参数值，并分析响应差异。在越权测试中，自动化替换Cookie并发送请求，是高效、精准定位漏洞的关键。手动替换十几次Cookie你可能就烦了，但Intruder可以轻松帮你完成几百上千次的测试，并且通过响应长度、状态码、关键词等条件快速筛选出可能存在问题的请求。

今天要聊的，就是如何将这套手动流程标准化、自动化。我将拆解从抓包到利用Intruder自动替换Cookie进行越权测试的五个核心步骤，并分享其中每一步的实战细节和避坑指南。无论你是刚接触Burpsuite的新手，还是想优化自己测试流程的老兵，这套方法都能直接拿来用。

2. 环境准备与目标分析：不打无准备之仗

在启动Intruder之前，充分的准备工作能让你事半功倍。这个阶段的核心是理清测试目标和配置好测试环境。

2.1 明确测试目标与权限模型

首先，你必须清楚你要测试的是什么。是水平越权（同权限用户访问他人数据）还是垂直越权（低权限用户访问高权限功能）？通常，你需要至少两个测试账号：

账号A（受害者/目标账号）：拥有特定的资源，例如用户ID=100的个人资料、订单号=2001的订单详情。
账号B（攻击者/当前登录账号）：用于发起测试请求的账号。在水平越权测试中，账号B与账号A权限相同但数据不同；在垂直越权中，账号B权限低于目标功能所需权限。

实操心得：在测试前，最好用两个账号分别完整走一遍关键业务流程（如查看个人中心、下单、管理后台等），并用Burpsuite的Proxy历史记录功能保存下这些请求。对比两个账号的请求，你就能快速发现哪些参数（如user_id,order_id,document_id）是可能被篡改的，以及Cookie的结构是怎样的。这比盲目测试高效得多。

2.2 Burpsuite与浏览器代理配置

这是基础但容易出错的环节。确保你的Burpsuite Proxy监听器正常运行（默认127.0.0.1:8080），并且浏览器或系统代理已正确指向它。

关键步骤与避坑点：

证书安装：对于HTTPS网站，必须在浏览器中安装Burpsuite的CA证书，否则无法解密HTTPS流量，你看到的将是乱码。证书导出路径通常在Proxy->Options->Import / export CA certificate。
浏览器配置：推荐使用Burpsuite自带的Chromium浏览器（从Proxy->Intercept->Open Browser打开），它已经自动配置好代理和证书，省去很多麻烦。如果使用自己的浏览器，请确保代理设置正确且证书已受信任。
拦截开关：开始测试时，建议先关闭Intercept is on（拦截开关），让流量先通过Burpsuite进入历史记录（Proxy History），方便你筛选和查找目标请求。等找到需要测试的请求后，再右键发送到Intruder。

注意：如果遇到网站使用了HSTS（强制HTTPS）或证书钉扎等机制，Burpsuite可能无法正常解密流量。对于现代App或复杂单页应用（SPA），还需要配合移动端代理或处理WebSocket流量，这属于更进阶的内容。

3. 核心步骤一：捕获并定位关键请求

自动化测试的起点，是一个正确的“模板请求”。这个请求必须包含有效的Cookie（代表一个已登录的会话）和你要测试的参数。

3.1 如何捕获有效的请求

使用账号B正常登录目标系统。
在浏览器中，访问一个需要权限的、包含目标参数的功能页面。例如，访问“我的订单详情”页面，URL可能为https://target.com/order/detail?order_id=2001。
此时，Burpsuite的Proxy History中会记录下浏览器发出的所有请求。你需要找到那个获取核心数据的请求。它通常不是一个简单的页面加载（GET/order/detail），而是页面通过Ajax异步加载数据的API请求。
寻找特征：查看请求的URL路径（如包含/api/、/graphql）、响应类型（application/json）以及响应内容（包含具体的订单信息、用户信息等）。这个请求的Request Headers里，一定会有Cookie字段，这就是你当前会话（账号B）的凭证。

3.2 识别待测试的Cookie与参数

找到目标请求后，右键点击它，选择Send to Intruder(快捷键Ctrl+I)。这时请求会被复制到Intruder模块的Positions标签页。

关键分析点：

Cookie位置：在Raw视图下，找到Cookie:请求头。它的值可能是一长串字符串，如session=abc123; user_token=xyz789。整个Cookie字符串通常需要被整体替换，而不是只修改其中某个键值对。因为服务端验证的是整个会话令牌的有效性。
目标参数：在URL查询字符串（如?id=100）或请求体（如POST的JSON{"userId": 100}）中，找到标识资源的参数。例如user_id、id、orderNo等。这些参数将是我们要用Intruder进行暴力替换的值。

一个常见误区：新手往往只关注URL里的参数，而忽略了请求体（Body）中的参数。对于POST/PUT请求，一定要切换到Params或Raw标签查看整个请求内容。

4. 核心步骤二：配置Intruder的攻击位置与类型

这是Intruder模块的核心配置环节，决定了攻击如何执行。

4.1 设置攻击位置（Positions）

在Intruder的Positions标签页，Burpsuite会自动用§符号标记一些它认为的可变参数。但自动标记往往不准，我们需要手动清除并重新标记。

点击Clear §清除所有默认标记。
标记Cookie：在Raw视图中，选中整个Cookie字符串的值（不包括Cookie:这个头名称），然后点击Add §。这时，Cookie值前后会被加上§符号，例如Cookie: §session=abc123; user_token=xyz789§。这告诉Intruder：“这是一个需要被替换的变量。”
标记目标参数：同理，选中URL或Body中你想要测试的参数值（比如id=§100§），点击Add §进行标记。你可以标记多个参数位置，Intruder会进行组合攻击。

4.2 选择攻击类型（Attack Type）

Intruder提供四种攻击模式，适用于不同场景：

攻击类型	英文名	工作方式	适用场景
狙击手模式	Sniper	使用一个载荷集合，依次替换每一个标记位置，其他标记位置使用默认值。	最常用。适合测试单个参数（如用户ID）或像Cookie这样的单个凭证替换。本次越权测试主要用此模式。
攻城锤模式	Battering ram	使用一个载荷集合，用同样的值同时替换所有标记位置。	适合需要多个参数保持相同值的场景，如用户名和邮箱同时替换。
音叉模式	Pitchfork	使用多个载荷集合，每个集合对应一个标记位置，按顺序一一对应地同时替换。	适合测试用户名和密码这种成对的数据，或者需要同时替换ID和Token的场景。
集束炸弹模式	Cluster bomb	使用多个载荷集合，对所有标记位置进行笛卡尔积组合替换。	适合测试多参数的所有可能组合，威力大但请求量爆炸式增长，需谨慎使用。

对于Cookie替换越权测试，我们首选Sniper模式。因为我们的目的是：保持其他参数（如id）不变，只系统性地替换Cookie字段，看看用不同用户的Cookie能否访问到同一个资源。

配置心得：在Positions子标签的Attack type下拉框中选择Sniper。你可以看到下方有一个Payload Positions的预览，清晰地显示了哪个位置将被替换。确保只有Cookie值被标记。

5. 核心步骤三：准备并加载Payload（Cookie列表）

Payload就是Intruder用来替换标记位置的“弹药库”。在越权测试中，我们的Payload就是不同用户的Cookie字符串列表。

5.1 获取Payload Cookie列表

这是测试能否成功的关键。你需要预先收集好多个有效用户的Cookie。

手动登录获取：分别登录账号A、账号C、账号D……，每次登录后，从Proxy History中复制对应账号访问任意授权接口时的完整Cookie请求头值。
从数据包中提取：如果你已经有一批抓包数据，可以使用Burpsuite的Extractor功能（在Proxy历史记录中，右键请求 ->Extract from response）或Match and Replace等高级功能批量提取Cookie，但这要求响应中包含Cookie信息。
从其他工具导入：有时Cookie可能来自爬虫或其他测试环节。

安全警告：这些Cookie必须是你在授权测试范围内合法获得的。绝对禁止使用非法手段窃取他人Cookie。

5.2 在Intruder中加载Payload

切换到Payloads标签页。
在Payload type下拉框中，选择Simple list（简单列表）。这是最直接的方式。
在下方的大文本框中，将你准备好的Cookie值列表，每行一个，粘贴进去。例如：
```
session=userA_token_abc123; remember_me=yes session=userB_token_def456; remember_me=yes session=userC_token_ghi789; remember_me=yes
```
重要格式：每一行都必须是一个完整、可直接放入Cookie:请求头的字符串。不要包含Cookie:这个键名。

5.3 设置Payload编码与处理

为了防止特殊字符破坏请求结构，通常需要关注Payload Encoding选项。

URL-encode these characters：默认是勾选的。对于Cookie值来说，它可能包含=、;、%等符号，Burpsuite会对其进行URL编码（如空格变%20）。大多数情况下，你应该取消勾选这个选项。因为Cookie在HTTP头中是以原始字符串传输的，如果被URL编码，服务端可能无法正确识别，导致会话失效。除非目标服务端程序有特殊处理，否则保持Cookie原样发送。
Payload Processing：可以在这里添加规则，例如对Payload进行哈希、追加前缀后缀等。在简单的Cookie替换中一般不需要。

注意：一个极易出错的地方是Cookie字符串末尾的换行符或空格。在文本编辑器中准备Payload时，确保行末没有多余的空格。粘贴到Intruder后，可以检查一下Raw视图预览，确认替换后的请求格式正确。

6. 核心步骤四：执行攻击与结果分析

配置完成后，就可以发起攻击并从中找出“异常成功”的请求了。

6.1 启动攻击与监控

点击Positions或Payloads标签页右上角的Start attack按钮。Intruder会弹出一个新窗口，开始按照Payload列表顺序发送请求。

攻击执行窗口详解：

请求列表：每一行代表一次请求，包含序号、Payload、状态码、响应长度、响应时间等。
原始请求/响应：点击某一行，可以在下方查看该次请求的详细内容和服务器返回的完整响应。

性能调节：如果请求量很大，可以在攻击窗口的Options标签页里调节线程数（Number of threads）和请求间隔（Throttle），避免对目标服务器造成过大压力或触发风控。

6.2 关键分析技巧：筛选越权成功请求

发送大量请求不是目的，从海量结果中快速找到“漏洞信号”才是。以下是核心分析方法：

排序筛选法：
- 按状态码排序：点击Status列排序。通常，成功的请求返回200 OK，未授权返回403 Forbidden或401 Unauthorized，找不到资源返回404。重点关注那些返回200状态码，但使用的Cookie并非资源所有者的请求。例如，用账号B、C的Cookie访问账号A的/api/user/100/profile接口，如果返回了200且响应体里是用户100的数据，那就存在水平越权。
- 按响应长度排序：点击Length列排序。不同状态的响应长度通常差异明显。成功获取数据的响应长度会远大于权限错误或资源不存在的响应长度。将长度异常的请求筛选出来重点查看。
对比分析法：
- 首先，你需要知道正常成功的响应是什么样的。用资源所有者（账号A）的Cookie发一次请求，记下它的状态码和响应长度。
- 然后，在攻击结果中，寻找那些状态码与正常成功相同（如200），但响应长度也极其接近的请求。这些请求很可能也成功获取了数据。
- 直接查看这些可疑请求的响应内容，与正常响应进行对比，确认是否包含越权数据。
查找关键词：
- 在攻击窗口的Options标签页，可以设置Grep - Match。添加一些只在越权成功时才会出现在响应体中的关键词，例如目标用户的用户名、邮箱、特定ID等。Intruder会在结果中标记出包含这些关键词的行，一目了然。

一个实战场景：测试用户信息查询接口/api/user/info?uid=100。你使用账号B（uid=101）的Cookie作为模板，Payload列表是账号A(uid=100)、C(uid=102)、D(uid=103)的Cookie。攻击后，你发现所有请求都返回200，且长度相似。这时你查看用账号C Cookie访问的请求响应，发现里面返回的uid、username字段竟然是100用户的信息，这就是一个典型的水*越权漏洞。

7. 核心步骤五：问题排查与高级技巧

即使步骤正确，实战中也可能遇到各种问题。这里分享一些常见的坑和进阶用法。

7.1 常见问题与解决方案

问题现象	可能原因	排查与解决思路
所有请求都返回403/401	1. Cookie已过期或无效。 2. Payload中的Cookie格式错误（如被URL编码）。 3. 目标参数本身就需要更高权限，与Cookie无关。 4. 服务器有IP或频率限制。	1. 确认Cookie来源请求是否新鲜有效。 2. 取消`Payload Encoding`的URL编码勾选，检查Cookie字符串完整性。 3. 单独测试用资源所有者Cookie访问，确认接口本身可通。 4. 降低攻击线程数，增加请求间隔。
响应长度一致，无法区分	1. 服务器对所有非法请求返回相同的错误页面。 2. 接口设计了统一的错误格式。	1. 使用`Grep - Match`搜索响应中成功时才有的唯一字符串。 2. 对比响应内容的细微差别，如错误信息JSON中的`code`字段。
请求被中断或连接重置	1. 触发了WAF（Web应用防火墙）规则。 2. 请求格式被篡改后异常。	1. 在`Payload Processing`中添加`Skip if matches regex`规则，避免包含明显攻击特征的Payload。 2. 在`Options`中设置`Follow redirections`，有时重定向是验证流程的一部分。
Intruder替换后请求格式错误	标记`§`的位置破坏了请求结构（如破坏了JSON格式）。	在`Positions`的`Request`视图仔细检查标记后的原始请求，确保语法正确。对于JSON，可以标记整个值部分，但不要破坏引号。

7.2 高级技巧：使用Pitchfork模式进行关联替换

在某些复杂场景下，单纯替换Cookie可能不够。例如，有些系统除了Cookie中的会话Token，还会在请求体或头中携带一个与用户绑定的X-User-Token或csrf_token。这时就需要关联替换。

标记两个位置：在Positions中，标记Cookie和X-User-Token两个变量。
选择Pitchfork模式。
配置两个Payload集：
- 在Payloads标签，Payload set选择1，加载用户1的Cookie到Payload 1。
- Payload set选择2，加载用户1对应的X-User-Token到Payload 2。
- 确保两个Payload集合的行数相同，且顺序对应（即第n行的Cookie和第n行的Token属于同一个用户）。
执行攻击：Intruder会使用Payload set 1的第一行替换第一个位置（Cookie），同时用Payload set 2的第一行替换第二个位置（Token），然后发送请求，以此类推。

这种方法能模拟出更真实的、携带多个关联凭证的请求，绕过一些简单的校验逻辑。

7.3 利用Turbo Intruder提升效率

当需要测试成千上万个Payload，或者目标服务器响应较慢时，原生的Intruder可能会非常耗时。这时可以使用Burpsuite的官方插件Turbo Intruder。它用Python编写，性能极高，支持异步请求和自定义处理逻辑。

基本使用思路：

在Proxy历史中右键目标请求，选择Extensions->Turbo Intruder->Send to Turbo Intruder。
在一个Python脚本环境中，你需要定义queueRequests和handleResponse函数。对于简单的Cookie替换，你可以修改模板，从文件读取Cookie列表作为Payload。
Turbo Intruder的优势在于可以极快地并发发送请求，并灵活处理响应，适合大规模模糊测试和竞态条件测试。

不过，对于大多数常规越权测试，掌握并熟练运用标准Intruder模块的这五个步骤已经完全足够。关键在于理解每一步背后的原理，并能根据实际的测试目标和目标系统的行为，灵活调整策略和参数。自动化工具放大了我们的测试能力，但真正发现漏洞的，还是测试者对业务逻辑和权限体系的理解深度。

查看全文

http://www.gsyq.cn/news/1623979.html