Burp Suite实战入门：Proxy抓包与Intruder爆破详解

Burp Suite是我觉得Web安全测试入门必须翻过的第一座山。很多新手刚开始接触渗透测试，打开Burp Suite看到一堆模块英文菜单直接懵了，不知道从哪里下手。实际上日常做Web渗透测试，你真正高频使用的核心模块就那几个：Proxy做流量拦截和抓包，Repeater做手工请求重放，Intruder做批量爆破和参数枚举。把这三个模块吃透，你就已经能应对大多数Web应用安全测试场景了。这篇文章我会从零开始，带你把Burp Suite两大核心模块——Proxy拦截和Intruder爆破——完整走一遍，顺便把中间衔接必备的Repeater也讲透，全程保姆级操作，照着做就行。

这篇教程适合完全没接触过Burp Suite的纯新手，也适合之前只会用某个模块、但对整体操作逻辑还不清楚的朋友。我会把每一步为什么要这么做都讲明白，而不是只告诉你点哪里。因为Burp Suite这类工具，你只有理解了它的工作逻辑——浏览器流量经过代理转发，Burp在中途拦截、修改、重放、爆破——才能真正玩转它，而不是背操作步骤。

1. 环境准备：先把Burp Suite跑起来

1.1 JDK版本选择和启动

Burp Suite是Java写的图形化工具，所以第一步要确保本机有Java运行环境。这里有个容易踩的坑：很多老教程让你装Java 8，但新版本的Burp Suite对JDK版本有要求，太老的Java版本会直接启动报错或者加载不了新版本功能。我建议直接用Java 11或者Java 17，这两个版本兼容性最稳。装好之后在终端执行java -version确认一下。

启动方式在Windows上是双击启动脚本或者生成的快捷方式，在Linux和macOS上是在解压目录下执行./burpsuite.sh。启动时会让你选择项目配置，新手直接用默认的Temporary project就行，点Next到底。这里我补充一句：如果你是在做真实渗透测试项目，建议用Burp Suite的桌面版配合外部配置文件管理，方便保存历史项目数据，但纯学习阶段临时项目完全够用。

1.2 设置浏览器代理

Burp Suite能拦截流量靠的是本地代理机制。默认情况下Burp在127.0.0.1:8080端口起一个HTTP代理服务，你要做的就是把浏览器的流量指到这个代理上。

以Chrome为例，设置里搜索"代理"，打开代理设置，把局域网代理开起来，地址填127.0.0.1，端口填8080。Firefox路径也类似。设置完成后你在浏览器里访问任何网站，流量都会经过Burp。

这里有个非常关键的知识点必须说清楚：你只需要设置HTTP和HTTPS代理到127.0.0.1:8080，把浏览器请求转发给Burp。Burp自己会处理后续的转发。这时候你在浏览器里访问http://burp，会看到一个Burp Suite的欢迎页面，说明代理已经通了。如果打不开，优先检查端口有没有被占用，或者代理地址是不是填错了。

注意：如果浏览器装了SwitchyOmega这类代理切换插件，它会覆盖系统代理设置。Burp的监听配置在Proxy模块的Options标签页里，默认监听127.0.0.1:8080，不要手动去改这个监听地址，除非你很清楚自己在干什么。

1.3 安装HTTPS证书

这一步是新手最容易卡住的地方。你会发现代理设置好了，访问HTTP网站能正常抓包，但一访问HTTPS网站，浏览器就报证书错误，页面根本打不开。这是因为Burp要对HTTPS流量做中间人解密，它需要让浏览器信任它的根证书。

操作流程是这样的：先打开代理，然后浏览器访问http://burp，点击页面右上角的CA Certificate按钮下载证书文件。下载完成后，在浏览器设置里搜索"证书"，导入该证书并勾选"信任此CA证书"。我用的是Chrome，导入路径是设置-隐私和安全-安全-管理证书-导入，导入时记得选择"受信任的根证书颁发机构"存储位置。

证书装好之后，HTTPS网站就能正常打开了，Burp也能解密看到明文请求和响应。这一步如果不做，你后续抓包只能看到一堆乱码，Intruder爆破更是无从谈起，因为发给Burp的HTTPS请求是加密的。

1.4 验证环境：用一个小流量确认抓包链路

环境配好以后，我强烈建议你先做一个连通性验证，而不是直接开始操作。打开Burp的Proxy模块，切到HTTP History标签页，然后把浏览器里随便打开一个网站，随便点几个页面。回到HTTP History，你应该能看到一条条流量记录。

验证的时候顺便看一下每个请求的Method、URL、Status Code这些字段，确认流量确实经过了Burp。这里顺便教大家一个小细节：HTTP History里字段很多，真正常用的就是Host（域名）、Method（请求方法）、URL（路径）、Params（参数）、Status Code（状态码）、MIME type（返回内容类型）。后面分析目标的时候，主要就是靠这些字段做筛选和排序。

做完这一步，你的Burp环境就完全通了。接下来进入Proxy拦截实战。

2. Proxy拦截与改包：抓包只是开始，会改包才算入门

2.1 Intercept开关的两种用法

Proxy模块下面有两个标签页最常用：Intercept和HTTP History。Intercept是实时拦截页，开关一开，经过Burp的请求就会暂停在这里，等你去修改；HTTP History是历史记录页，所有经过的流量都自动记录在这里，方便你事后筛选和分析。

新手容易犯的一个错误是：一直开着Intercept开关，结果浏览器打开任何页面都卡住不加载，还以为工具坏了。实际上这是拦截功能正常工作的表现。Intercept开关的使用分两种情况：

情况一：你想主动看某个请求并修改它，那就开着Intercept，触发目标操作，请求停在拦截页，修改完点Forward放行。情况二：你不需要拦截，只需要记录流量做事后分析，那就把Intercept关掉，让流量直接通过，然后去HTTP History里看记录。

我的习惯是日常浏览时Intercept保持关闭，等需要测试具体某个功能点时再临时打开。你可以把Intercept理解为"设卡检查"，HTTP History理解为"监控录像"，两者配合使用才能高效。

2.2 改包的完整流程：以修改请求参数为例

假设你要测试某个搜索接口的参数注入，最直接的改包操作流程是这样的：

打开Burp的Intercept开关。在浏览器搜索框里输入一个关键字，提交搜索请求。请求被Burp拦截住，这时候你能在Intercept页看到完整的请求报文，包括请求行、请求头、请求体。在Raw视图下，直接修改请求体里的参数值，比如把search=test改成search=test'，看看后端会返回什么。如果改完发现响应异常，说明参数处理可能存在问题。

改完点Forward放行，请求带着你修改后的内容发往服务器。然后你切到HTTP History，找到刚才那条请求，看Response响应内容。

这个流程就是Web安全测试里最基础、最核心的"手工测试"路径。几乎所有漏洞挖掘——SQL注入、XSS、越权、逻辑漏洞——都是从这个小流程演变出来的。你说Burp难吗？操作上不难，难的是你对HTTP协议的理解。

2.3 HTTP History的筛选和搜索技巧

流量记录多了以后，你会发现HTTP History越来越长，要找一条请求非常费劲。这时候就需要用筛选功能。HTTP History页上有Filter输入框，支持按URL、MIME类型、状态码等条件过滤。常用操作有这么几个：

按域名过滤：在Filter里输入目标域名，比如target.com，历史记录就只显示该域名的请求。按MIME类型过滤：比如只看JSON类型的响应，可以输入mime:json，快速定位API接口。按状态码过滤：想看成功的请求就过滤status:200，想看跳转就过滤status:3。按关键词搜索：直接在Filter里输入搜索词，Burp会自动匹配URL和参数中包含该词的请求。

另外HTTP History里右键点击任意请求，菜单里有一堆操作选项，最常用的是Send to Repeater（发送到重放器）和Send to Intruder（发送到爆破器）。这两个操作就是把一条请求从"被动记录"变成"主动攻击"的桥梁，后面两部分内容就是围绕这两个操作展开的。

2.4 实战心得：分组与颜色标记

信息量比较大的测试场景下，我习惯用颜色标记配合分组来管理流量。选中请求右键，可以看到Color Tags菜单，可以把特定接口标成红色、绿色等。比如把所有登录接口标成红色，把所有订单操作标成蓝色，这样在宏观视图下，整条业务链路一目了然。

新版本的Burp还有Request Groups功能，类似文件夹分类，可以把同一个业务流程的请求归到一组。这个功能特别适合测试完整业务流的时候用——比如注册-登录-下单-支付，一条链路几个请求，放在一组里，前后对比改动就很清楚。

3. 衔接利器Repeater：手工测试的黄金工作台

3.1 从Proxy到Repeater的核心操作

Repeater是Burp里我待得最久的地方。它的作用一句话说清楚：把一条请求固定下来，你随时修改、随时重放、随时看响应。不需要重新在浏览器里操作一遍，效率高得多。

把一条请求发送到Repeater非常直接：在HTTP History里选中某条请求，右键选择Send to Repeater。Burp会打开Repeater标签页，上面是这个请求的完整报文，右侧是响应区。

在Repeater里，你可以任意修改请求的任何部分——URL路径、请求头、Cookie、请求参数——改完点右上角的Send按钮，右侧立刻显示新的响应。你可以对比不同修改对应的响应结果，这就是手工漏洞测试的工作模式。

3.2 Repeater的实用改包场景

我用几个常见测试场景来说明Repeater的实战价值：

场景一：测试IDOR越权。比如某订单查询接口URL是https://target.com/order/1001，在Repeater里把1001改成1002，Send一下，如果响应里返回了1002订单的详细信息，说明接口存在越权问题。这个测试在浏览器里做也行，但在Repeater里做更高效，因为你可以连续改好几个ID快速验证。

场景二：测试SQL注入。登录接口的请求体里是username=admin&password=123，在Repeater里把password改成123' or '1'='1，发送后看响应是否出现数据库报错信息或者登录成功。

场景三：测试权限绕过。有些接口仅前端做了按钮权限控制，后端没有校验。你在Repeater里直接对管理接口发送未经授权的请求，如果返回200且带数据，就说明后端权限校验缺失。

3.3 Repeater的分组和标签管理

请求一多，Repeater窗口顶部会积累一大堆标签页。新版本的Burp有Tab分组功能，和Proxy模块的分组类似。我在测试一个站点时，会把登录相关请求放在Login组，把用户查询接口放在User组，把支付相关接口放在Pay组。分组管理的好处是逻辑清晰，尤其在项目周期长、测试点多的渗透测试任务里，这个习惯能帮你节省大量找请求的时间。

Repeater还有一个细节容易被忽略：请求方法、请求体里参数的显示顺序，直接编辑即可。URL参数在后面我需要调Intruder时，都用得上这里固定的请求作为原始模板。所以每次在Repeater里准备一个干净的"基线请求"，是整个测试流程的起点。

4. Intruder爆破：从配置到实战的完整解析

4.1 什么是Intruder，它能做什么

Intruder模块是Burp Suite里做自动化批量请求的引擎。它的核心能力是：拿一条固定请求当模板，自动替换里面的参数值，反复发送大量请求，并根据响应帮你判断哪些是有价值的结果。

最常见的两个使用场景：登录爆破——把用户名或密码参数设为变量，批量尝试不同组合；参数枚举——把ID设置为变量，批量枚举订单号、用户号。还可以用来遍历字典——把Payload位置设为变量，跑一个敏感路径字典。这就是标题里"爆破"两个字的全部含义。

使用Intruder有两个先决条件：一条抓到的真实请求，和一个靠谱的字典。

4.2 4种攻击类型怎么选

很多人用Intruder最懵的是Attack Type怎么选。这4个选项背后是不同场景的自动化逻辑，选错类型结果全错。我把它们拆开讲。

首先是Sniper（狙击手）。它是单字典模式：字典文件中每个条目依次替换请求中标记的§符号位置。如果标记了一个位置，就逐个替换那个位置；标记了两个位置，就先把字典都用完在第一个位置，再全部用到第二个位置。它适合单参数测试，比如只爆破密码，用户名固定为admin。

其次是Battering Ram（攻城锤）。它也是单字典模式，但跟Sniper的区别是：多个标记位置同时使用同一个值。比如你标记了用户名和密码两个位置，字典第一个值是test，它会把用户名和密码都替换成test，再发送请求。这个类型用的场景不多，偶尔用于测试多个参数值相同的接口。

然后是Pitchfork（草叉）。它是多字典并行模式：多个字典文件按顺序一一对应组合。比如第一个字典放用户名列表，第二个字典放密码列表，第一次请求用第一行用户名+第一行密码，第二次用第二行+第二行。这种模式适合你手里已经有一批"用户名-密码"对应组合的情况，精准测试撞库。

最后是Cluster Bomb（集束炸弹）。它是多字典笛卡尔积模式：所有字典的所有可能组合都会跑一遍。比如3个用户名和100个密码，就会产生300个组合请求。这种模式最暴力、请求量最大，适合多参数组合爆破，比如同时枚举用户ID和订单状态值。

四种类型我用一张表总结：

4.3 Payload位置标记与Payload配置

Intruder配置界面上有4个标签页：Target（目标）、Positions（位置）、Payloads（载荷）、Options（选项）。新手大部分困惑出在Positions和Payloads的配合上。

Positions页面展示的是请求报文，里面已经用§符号标注了Payload位置。Burp默认会将URL、Cookie、请求体里的参数值都自动标记为位置，但你通常需要手动调整。点一下"Clear §"可以清除所有标记，然后选中你要爆破的参数值，点"Add §"把那个值用§符号包起来。

我举个例子。一个登录请求的请求体是：

username=admin&password=123456

如果你只想爆破password，就应该把标记清掉之后，只把123456用§标记起来，变成username=admin&password=§123456§。发送请求时，Intruder会把§之间的内容替换成字典里的值。

Payloads页面是设置字典来源的地方。最常用的是Simple list（简单列表），你可以直接点Paste把文本列表粘贴进来，或者从文件Load。但很多人不知道，Burp还内置了类型丰富的Payload生成器。

比如Numbers类型可以直接生成数字序列，爆破6位短信验证码就用Numbers从000000到999999，设置Min/Max数字范围和Step。比如设置Min=000000，Max=999999，Step=1，Burp会依次把这些值替换到标记位置。还有Null payloads类型。这种Payload本身是空值，但它可以配合发送次数上限使用来生成多次重复请求。如果你要刷一个带随机数的请求，Null Payloads配合Generated每次变换，就很有用。

实际爆破中跑多少请求、用什么顺序，完全由Payloads设置决定。你还需要在Request Count那里看到预计的总请求数量，方便评估爆破时间。

4.4 Options配置：线程数、重定向与结果标记

Options页面是很多新手忽略但很关键的地方。这里有几个设置直接影响爆破成功率和稳定性。

线程数（Number of threads）是最大杀手。很多人图快，直接把线程拉到50、100，结果目标服务器扛不住，要么Ip被Ban，要么请求全部超时，爆破结果一堆错误。我的经验是：普通小站线程设在10到20之间，大一点的目标可以到30，但初次爆破一个不熟悉的目标时，先用5到10个线程试一小批字典，确认目标反应正常后再调大。

重定向处理。有的登录接口爆破时会返回302跳转，Burp默认不跟随重定向，这可能导致你看到结果全是302，无法判断是否成功。这里需要你在Options里设置Redirects处理方式。通常使用"Follow"模式，或者在重定向规则里选择"Always follow"。

Grep-Match功能。这个功能特别实用：你可以设置一些关键词，比如"欢迎、退出登录、错误、验证码"等，然后爆破结果里会自动标记出哪些响应包含这些关键词，方便你快速找到有效请求。比如爆破后台登录，如果匹配到"欢迎"的响应，很可能就是爆破成功了。

响应结果排序。Intruder完成爆破后，结果列表按Length列排序这个操作非常高效。因为正确请求的响应长度，往往和错误请求差异很大。排一下序，异常长度的就浮出水面了。

4.5 爆破结果分析实战

爆破结果怎么判断？我以最简单的登录爆破为例，假设你爆破密码，服务器返回200是登录成功，返回401是密码错误。那你直接在Status Code列筛选200即可。如果服务器不管对错都返回200，靠状态码就不够了，这时候看响应长度。登录成功后响应体通常包含大量用户信息、跳转地址，长度明显不同于失败响应。把Length列降序排，最长那条大概率是成功的。

更高级一点的判断方法是配合4.4里的Grep-Match提前设置成功特征词。我举个例子，登录成功响应里包含"userInfo"这种字段，失败响应里只有"error"，那就在Grep-Match里加userInfo，跑完后看哪条请求被标记。

注意，爆破结果不要只看状态码200这一个维度。有的系统登录失败也返回200，但返回体里带登录失败提示。有的系统登录成功返回302跳转到首页，你反而要关注302这一批。总之要结合状态码、响应长度、关键词三个维度综合分析。

5. 常见问题与排查技巧实录

5.1 抓不到HTTPS报文，全是乱码或证书警告

这几乎是我被问得最多的问题。表现是浏览器打开HTTPS网站报证书不安全，Burp的HTTP History里要么没有流量，要么流量解密后是乱码。原因几乎都是证书没有正确导入，或者导入后没有勾选受信任。

解决步骤：重新下载Burp CA证书；在浏览器证书管理里删除之前导入的证书；重新导入，存储位置务必选"受信任的根证书颁发机构"；重启浏览器，再验证。

有个更容易翻车的细节：某些系统应用不走浏览器代理，比如手机App、桌面客户端。你配了浏览器代理，Burp却抓不到App流量，因为App根本不走那个代理。如果你需要抓App流量，需要额外配置系统级代理，这里不展开，但你要有这个认知。

5.2 Intruder爆破速度慢或者被目标屏蔽

爆破显示大量超时或者目标直接拒绝服务，多半是线程数设置太高，或者请求频率过快。遇到这种情况先把线程降到10以下，再在Options里增加请求之间的延迟。Burp没有全局延迟设置，你可以在Resource Pool里限定这个攻击任务的并发上限。我习惯把并发限制在10，宁慢勿崩，因为爆破的本质是批量发送请求，关键是结果稳定，不是跑得快。

另一个可能导致异常的是字典质量问题。一个包含大量空行、重复内容的字典，跑出来的结果会让你分析到崩溃。字典用之前先整理一遍：去重、去掉空白行、统一大小写，这些基础工作别省略。

5.3 爆破结果全部相同怎么排查

爆破跑完了，几百条结果状态码一样、长度一样，几乎无法区分。这种情况往往是Payload位置标记错了。你清标记时把不该清的也清了，或者标记位置只标了一个但字典没真正作用到目标参数上。回到Positions页面仔细确认§符号的位置是否正确包裹了参数值。

还有可能是网站存在验证码或请求频率限制，后端根本没走你的Payload逻辑，直接返回统一提示。这时候你需要在Repeater里先用几条手工请求验证一下目标是否对你的批量请求敏感。

5.4 改包后响应没有变化

在Repeater里改参数后，响应和之前一样不变。这个现象常见于两种情况：一是参数本身是展示型参数，后端不校验不处理，改了自然没变化；二是请求体格式不对，比如Content-Type声明的是JSON，但你改成了普通表单格式，后端解析不到你的参数值，自然走默认逻辑。

排查方法是先看响应长度有没有微小的变化，从状态码、响应时间、Content-Length这些字段判断后端是否真的处理了你的请求。如果确认都没变化，再考虑换个参数标记位置测试。

5.5 个人经验：建立属于自己的测试流程

工具掌握到最后，拼的是流程和习惯。我建议你从第一天就用一个固定的测试顺序，不要今天抓包明天就直接爆破。我个人的标准流程是这样的：先浏览目标站点，把关键功能点记录下来；然后用Proxy正常流量记录，把每个功能点的请求都发到Repeater保存在分组里；接着在Repeater里手工测试参数变化；最后才用Intruder进行参数枚举和爆破验证。

这个流程里最容易被跳过的环节是"手工测试"。很多人在Repeater里改了第一个参数没发现问题，就急着上Intruder跑字典，实际上手工测试先发现的基础问题，会直接影响你Intruder的配置方向。比如手工测试发现某参数需要特定格式，Intruder字典就要做对应处理，否则跑一堆无意义请求。

最后再分享一个小技巧：Intruder爆破之前，先拿一小段测试字典（比如10条）跑一遍，确认请求发送、响应接收都正常，再跑全量字典。这10条请求的成本极低，但能帮你提前发现配置错误，避免浪费大把时间在错误配置上。

实际上Burp Suite的这几个模块，每一个单独拿出来都可以写很长的文章，但真正影响你实战水平的往往是最基础的配置和逻辑习惯。Proxy、Repeater、Intruder串起来，就是一条完整的测试链路：拦截流量、分析请求、手工测试、自动化验证。把这套链路跑通，你就已经具备独立测试普通Web应用的能力了。