很多刚接触接口调试或Web安全测试的朋友，第一次打开Burp Suite是一脸懵的状态——界面上密密麻麻的按钮，菜单全是英文，很容易让人退缩。但如果你真正把抓包、改包、重放、爆破这四个核心环节串起来，就会发现Burp Suite其实是一个非常顺手的工具：它就像你在浏览器和服务器之间插了一面镜子，所有请求都经过它，你可以看、可以改、可以反复发送、可以对同一个接口做大量参数验证。这篇文章不整那些花里胡哨的理论，我会直接按一条完整的实操链路，把这四个模块从配置到实战，一点一点捋清楚，适合刚接触Burp Suite、或者装了但没真正用起来的朋友参考。
1. 学之前先弄明白：Burp Suite 在调试和测试里的真实位置
1.1 它和 Fiddler、Charles、Wireshark 到底有啥不一样
很多人会一上来就纠结：“我该学Burp Suite还是Fiddler？还是Wireshark？”这个问题其实不难，关键是看你想要干什么。Fiddler和Charles的核心场景是抓包查看，尤其适合前端联调、页面请求排查、App接口抓取，它们对HTTPS流量的解密做得很傻瓜化，打开就能用，对于日常开发和调试来说非常舒服。Wireshark则是另一种思路——它工作在网卡层面，抓到的是机器进出的所有网络数据包，不光能看HTTP/HTTPS，还能看DNS、TCP、UDP、ARP各种协议，属于底层网络分析工具。
Burp Suite的定位会和它们区分开，它是一个“面向安全测试和接口深度验证”的工具。它可以抓包，但这个“抓包”只是起点，更核心的价值在于改包、重放、爆破，以及后面扩展出去的扫描、爬取、解码、比对等能力。换句话说，Burp Suite给了你一个可以控制整个HTTP生命周期的团队，而不是只给你一个望远镜。它默认就支持你拦截后篡改请求头、请求体，在Repeater里对单条请求反复发送，在Intruder里把接口参数做成批量字典来跑——这些操作在Fiddler里也能做一部分，但体验和深度完全不一样。
我建议你把它理解成一个浏览器和服务器之间的代理，Burp Suite监听在本地某个端口上，比如http://127.0.0.1:8080，浏览器或手机的流量都指向这个代理地址，Burp看到之后再转发给目标服务器。整个链路里，Burp对你完全透明，但每一步它都能插手。
1.2 学习版和专业版差在哪，要不要花钱
要不要用付费版，我的看法是：除非你要用那些高级扫描功能，否则Community版足够你学完抓包、改包、重放和爆破的所有基础操作。专业版多出来的东西主要是主动扫描器、被动扫描、Saved Session、扩展库更新、爬虫这些攻击面更大的功能，对刚入门的人反而是负担。
但是要注意，Community版里Intruder有一个重要限制——爆破速度被限得很慢。单线程跑还好，并发一高就会被节流，这是官方故意设置的，用来区别付费用户。不过从“理解爆破原理”的角度来看，慢有慢的好处：你能更清楚地看到每条请求的生命周期，也不会一不小心就把目标接口打崩。学完了基础操作，以后有工作需要再升级专业版，学习成本已经归零，功能也只是锦上添花。
1.3 正式开始前的测试环境准备
工欲善其事，必先利其器。我的习惯是先用官方提供的靶机环境练手，而不是直接拿线上系统做实验。比如业内常用的PortSwigger Web Security Academy，它自带实验环境，专门给Burp Suite用户练手，里面从SQL注入、越权到逻辑漏洞都有。自己本地也可以搭，比如用DVWA、bWAPP或者一个简单的Java/Node项目，把环境开在本地，就能放心大胆地抓、改、爆破。
如果你是第一次上手，我建议就在自己电脑上做一次完整的“请求闭环”实验：开一个本地服务，比如python3 -m http.server 8000，然后用Burp Suite来抓浏览器访问这个服务的流量，改几个参数看看效果，再去Repeater里重放。这样成本最低、也最容易验证每一步操作到底有没有生效。
2. 抓包教学：代理、证书与 HTTPS 流量处理的完整链路
2.1 配置代理，让浏览器先“听话”
Burp Suite默认会在启动时监听127.0.0.1:8080，代理入口在Proxy模块下的Options标签里。你可以看到一行地址，形如127.0.0.1:8080。
如果你用的是Chrome/Edge这类现代浏览器，处理起来比较麻烦的一点是系统代理设置和浏览器代理设置不一定同步。最简单的测试办法是直接用一个独立的浏览器配置启动，比如Chrome用这种参数启动：
chrome --proxy-server="http://127.0.0.1:8080"或者干脆在浏览器设置里安装一个代理插件，例如SwitchyOmega，在插件里加一个情景模式，HTTP代理设为127.0.0.1，端口填8080，保存后点一下切换，整个浏览器流量就走过去了。我个人的经验是：你以后可能经常要在Burp代理和无代理之间切换，有一个像SwitchyOmega这样的插件会省很多事，远比每次手工改系统代理方便。
在Burp的Proxy > HTTP History里，只要代理配置成功，你就能看到浏览器发出的一堆请求，每一行都包含方法、URL、状态码、MIME类型、请求来源和大小。这时候你就完成了第一次“抓到包”。
2.2 HTTPS 证书安装：为什么你配置了代理还是抓不到内容
如果你只是访问HTTP网站，配置好代理后立刻就能抓到。但碰上HTTPS网站，比如你现在经常访问的各种App、接口、小程序，默认情况下你抓到的只会是一堆乱码，甚至Burp会提示证书不受信任，因为浏览器在做TLS加密握手时，不认Burp这个中间人的证书。
解决办法是让浏览器信任Burp自己签发的根证书。
第一步，先在Burp里导出证书。在Proxy Options里，找到并点击Import / export CA certificate，然后选择Export，格式选Certificate in DER format，保存为一个.der文件。
第二步，安装证书到系统的受信任根证书颁发机构。Windows上双击这个文件就会弹出安装向导，安装位置要选“本地计算机”，然后“将所有证书都放入下列存储”，点浏览选中“受信任的根证书颁发机构”。macOS上则需要通过“钥匙串访问”导入，然后右键标记为“始终信任”。
第三步也是很多人漏掉的一步——装完证书后一定要重启浏览器。HTTPS连接中的证书信任状态在很多浏览器里是缓存在进程里的，仅刷新页面不一定生效。等它生效后，再打开HTTPS页面，Burp里请求的状态码就能正常显示200，请求头里的Host、User-Agent、Cookie全都能看清楚了。
提示：证书只在你自己的测试环境里安装，不要随便把Burp证书导入到公共电脑或生产环境，否则会导致中间人攻击的风险。
2.3 手机端与App抓包：模拟器、真机和“无root”方案
现在的接口测试很多场景都在手机上，特别是微信小程序、App内嵌H5这类流量，纯浏览器根本模拟不出来。手机抓包的思路其实不复杂：让手机和电脑处于同一个局域网，手机Wi-Fi代理指向电脑的局域网IP和Burp的8080端口，然后手机浏览器访问http://burp下载并安装证书。但这个方案在实践中经常遇到两个问题：一是安卓App默认不信任用户CA证书，二是App可能做了证书校验。
如果你的测试条件允许，优先考虑用模拟器加Android 7以上系统的方案，在模拟器里把Burp证书装成系统级证书。把证书转成.pem格式后，放在系统system/etc/security/cacerts目录下，这个操作需要模拟器允许系统分区写入。有些模拟器，比如一些国产安卓模拟器，自带root开关，打开root后就可以直接push进去，完成后重启模拟器，再用Burp抓App流量就畅通了。还有一种方式是给模拟器装LSPosed框架，配合TrustMeAlready、JustTrustMe这套模块——这类模块的作用是绕过App内部的证书校验，让流量能够走系统代理。没有root的设备上，很多测试会因为证书固定机制而失败，这也是大家说的“无法抓包”问题的常见根源。我自己在这种情况下的经验是：优先换root模拟器，省去很多折腾时间。
2.4 开拦截还是只观察？这是个习惯问题
刚上手时，我最推荐的习惯是：初期观察用History，动手修改再开拦截。什么意思呢？
Burp的Proxy模块里有一个Intercept按钮，默认是开启的。开启时，所有经过代理的请求都会被冻结在界面上，你要手动点Forward，请求才会继续发出去。这个模式适合你明确知道要改某个请求时使用。但如果只是正常浏览网站，想看看页面都请求了哪些接口，你会觉得每发一个请求就要点一次Forward，非常烦躁。
所以，需要观察时就打开HTTP History，把Intercept关掉；需要修改时再打开Intercept。这个开关状态其实非常影响使用体验，很多人一开始抓不到包，打开一看，发现所有请求都被Intercept卡住了，按钮是亮着的，但不知道要Forward，就以为哪里配置错了。
3. 改包教学：拦截请求乱改才是真实力的开始
3.1 一条请求里哪些部分能改、改完有什么影响
在Burp里，你可以把一条HTTP请求拆成三块来看：请求行、请求头、请求体。请求行包括方法、URL路径和HTTP版本。请求头是Host、Cookie、User-Agent、Authorization等一系列键值对；请求体常见于POST请求，可能是JSON、XML或表单数据。
这三个部分里，任何一部分你都能在拦截时直接修改。但这种修改“改得对不对”不是Burp来判断的，而是由目标服务器来验证。比如你登录一个系统时用的是自己的Cookie，你在拦截中把一个Red packet金额从100改成1，这个请求发给服务器后，服务器到底认不认，取决于它的后端逻辑是否有校验。
所以改包测试的核心价值在于：验证后端信任边界是否可靠。很多开发者做接口时只验证了参数名称和基本格式，却忽略了业务权限、价格、数量、用户ID这些“冷门字段”的合法性，于是你在Burp里把一个ID改掉，就可能访问到别人的数据；把价格改成0.01，就可能产生一张异常订单。这类“越权”和“逻辑绕过”测试，只有在改包这个环节才能高效完成。
3.2 完整演示：拦截一次登录请求并修改参数
我们拿一个最经典的场景来说：假设有一个登录接口POST /api/login，表单参数是username和password。
第一步，打开Burp的Proxy，确认Intercept是开启状态，然后在浏览器里输入用户名和密码，点击登录。这时候你的请求不会立即发出，而是停留在Burp的Intercept标签页里。你能看到类似这样的代码块：
POST /api/login HTTP/1.1 Host: test.example.com User-Agent: Mozilla/5.0 Content-Type: application/x-www-form-urlencoded Cookie: sessionid=abc123 username=admin&password=123456第二步，改请求体。比如我们在请求体后面加一个&isAdmin=true，或者把username改成test，或者更彻底一点，把请求方法从POST改成GET并把参数放到URL里，观察服务器是否会报错、是否会按新参数处理。
第三步，点Forward按钮，让请求放行，然后在HTTP History里找到这条交互记录，观察服务器响应。你会发现，改包只是第一步，真正有意思的是观察服务器对这个改动做出的反应——这就建立起了“请求-响应”之间的因果直觉。
注意：Intercept里修改的内容不会立刻生效，只有在你点Forward之后才会真正发出去，点Drop则会把这条请求丢弃，不发往服务器。实际测试中如果按错了Drop，就等于这次操作作废，需要重新在浏览器里触发一次。
3.3 全局替代：Match and Replace，省掉重复手工劳动
拦截改包适合精修单条请求，但有时候你想把每条请求里的某个固定值统一替换掉，比如把所有的User-Agent改成一个特定的移动端标识，或者把请求体里的某个token字段替换为新值。再手工一条条去改，效率太低了。
这时候可以用Burp的Proxy > Options > Match and Replace功能。它的原理很简单：Burp在转发请求前，先对请求内容做一次“查找替换”，命中规则后自动替换。比如我配置一条规则，把User-Agent: Chrome替换成User-Agent: iPhone，那么浏览器发出的所有请求到了Burp这里都会被改成iPhone标识再发给服务器，整个过程不用人工干预。
这个功能在移动端接口调试时特别实用。有些接口会做UA限制，PC端请求根本拿不到正常响应，你可以用Match and Replace把UA统一伪装成手机浏览器，解决起来很快。而且它支持正则表达式，熟练之后你可以做得非常精细，比如只替换URL里的某个query参数。
4. 重放模块精讲：利用 Repeater 做接口精准验证
4.1 一条请求右键发送到 Repeater，后续操作全在这里
抓包和改包解决了“看”和“临时改”的问题，但实际测试中还有一个高频需求：我想对同一条请求反复测试，比如修改一个参数看响应变化，或者在接口上加不同Header观察认证逻辑。每次重新触发页面请求再拦截显然太繁琐，而且还容易混进其他干扰请求。
Burp的Repeater模块就是为了这个场景设计的。操作非常简单：在Proxy的HTTP History里，找到目标请求，右键菜单里选择Send to Repeater，快捷键是Ctrl+R。然后在顶部标签栏切到Repeater，你的请求已经躺在Request面板里了。
我常用的做法是，把请求面板左边改成“Pretty”显示模式，看起来可读性更好。右侧是Response窗口，点一下Send按钮，请求就会被原封不动发出去，响应立刻回显在右侧。你可以不断修改左侧请求体、请求头，再点Send，观察右侧响应变化。
4.2 重放一个登录接口，实际体会响应逻辑的差异性
举例来说，假设刚才那条POST /api/login请求已经被发到了Repeater里。第一次我原样发送，服务器返回“密码错误”；第二次我把密码改成正确值，返回“登录成功”并附带一个cookie；第三次我把用户名改成admin但是密码错误，观察错误提示是否一致；第四次我把Content-Type改为application/json、请求体改成JSON格式，看看服务器会不会直接返回400。
这几步下来，你能得到的信息量远比单次登录测试多：你会知道服务器对参数类型是否敏感、是否泄露用户是否存在、错误逻辑是否统一。这样的一条请求，如果只靠浏览器反复登录做测试，不仅效率低，还容易被页面交互逻辑干扰。Repeater给了你一个快速、干净、可重复的测试沙盒。
我还喜欢在Repeater里给请求添加多个不同的Header观察效果。比如有些接口在无Authorization时返回401，在带上伪造的Bearer Token时返回403还是200，一下就能看出接口的鉴权粒度。你可以把一组相关Header在请求面板里用复制粘贴的方式快速组合，比每次通过页面触发的效率高很多。
4.3 Repeater 的隐藏细节：自动更新 Content-Length 与 Cookie 管理
这里有一个新人比较容易踩的坑：改了请求体内容，比如把一个字符串从3个字符变成10个字符，但请求头里的Content-Length可能仍然写的是旧值，服务器在解析时就会因为长度不匹配而迟迟不响应或直接报错。旧版本的Burp可能需要你手动同步更新Content-Length，新版本里通常Burp会自动帮你计算更新，但你要养成一个习惯：改了请求体之后看一眼Content-Length是否已经变化。
另外，Repeater本身不会自动维护cookie状态。你在浏览器里登录之后的会话Cookie不会主动带入Repeater的请求里，除非你手动把Cookie从History里复制过来，或者在Repeater设置里开启Update Content-Length和设置Cookie Jar。Burp有一个Cookie Jar的概念，在Proxy和Intruder场景中可以统一管理会话，在Repeater里也可以选择使用什么Cookie发送。如果你想重放一个需要登录态的接口，最简单的办法是把刚刚从浏览器里抓到的Cookie字符串直接粘贴到请求头的Cookie字段里。
提示：很多高级用法其实都藏在右键菜单里。在Repeater面板中选中一段数据，右键可以选择“Send to Comparer”“Send to Intruder”，甚至能对响应做“Search”定位关键词，这些功能单独拆开看都很微小，但组合起来会让测试链路变得异常顺手。
4.4 为什么说 Repeater 和 Intruder 是两种思维
Repeater的单条反复发送，本质上是在验证“单点逻辑”；而Intruder是把同一请求批量发送多个参数组合，本质上是在做“自动化参数枚举”。很多刚上手的朋友会困惑：爆破模块到底和Repeater有什么关系？我的理解是：一切先放在Repeater里做小样本验证，确认了你想要修改的参数位置和响应判断条件后，再无缝切换到Intruder去扩大测试面。这才是两者配合使用的正确节奏。
5. 爆破模块教学：Intruder 的四种攻击模式与字典构建思路
5.1 四种攻击模式的核心差异，别再瞎选了
Intruder里新建一个攻击配置时，它会让你选择攻击模式。正确理解这四种模式，是能不能高效使用爆破模块的关键。
我们先看Payload Position，也就是请求里被标记成§的占位符。你在请求面板中选中参数值，点击Add，参数就会变成类似这种形式：
username=§admin§&password=§123456§然后，四种模式的区别就体现在多个Payload Position如何被赋值上：
- Sniper（狙击手）：一次只对一组位置用字典里的一个值，其他位置保持原样。它适合只有一个参数需要枚举的情况，比如把用户名字典一轮一轮替换，密码固定。速度较慢，因为字典遍历次数会按位置数量成倍增加。
- Battering ram（攻城锤）：所有位置同时使用同一个Payload值。它适合那些需要“同步一致”的场景，比如你要同时修改密码和确认密码这两个字段，让它俩始终相同。
- Pitchfork（草叉）：多个位置分别绑定多个Payload列表，按索引同时取一个值进行组合。它适合用户名字典和密码字典一一对应的情况，比如第1个用户名对应第1个密码，第2个用户名对应第2个密码。
- Cluster bomb（集束炸弹）：所有位置取各自的Payload字典做一个笛卡尔积。如果两个位置的字典大小分别是N和M，最终请求量是N乘M。它适合做组合爆破，比如用户名字典和密码字典全组合，但需要非常小心请求量，尤其对线上的接口，一个不留神就会产生远超预期的流量。
这四种模式里，我最常使用的是Sniper和Cluster bomb。Pitchfork虽然逻辑听上去很优雅，但实际测试中你很少会有“一一对应”的现成字典，更多时候是组词式的自由组合。
5.2 字典怎么来：不要只会用网上所谓的“常用密码表”
爆破效果好不好，字典质量要比爆破速度重要得多。网上几十G的通用字典看起来威风，其实命中率很低，原因很简单——它们没有结合目标业务去定制。
我通常的字典构造逻辑是这样的：先做信息收集，通过抓包看接口返回提示，比如用户名不存在和密码错误是两种不同的响应，说明这个接口可能允许用户名枚举；再看网站或App的注册规则，有些系统要求密码必须包含大写字母和数字，那么纯小写字母字典直接废掉；还要观察有没有验证码、短信校验、账户锁定策略，这些如果存在，爆破策略又得重新调整。
如果一个接口没有验证码，没有次数限制，且登录错误提示区分明显，那你可以从这几条线的字典开始：
- 默认口令：admin/admin、admin/123456、test/test这种组合特别容易中招，很多内部系统上线后根本来不及改初始密码。
- 用户名枚举后的定向字典：先跑到一个存在的用户名，比如
zhangsan，再给这个用户跑一个小而精的密码表，比漫无目的全量爆破命中率高十倍。 - 基于日期、姓名拼音、手机尾号组合：比如
zs19920815、13800138000这种口令，属于很多人习惯性的“安全密码”，但恰恰这类密码才是测试中最常见的弱口令形态。
在Intruder里，Payload标签页可以选择手动粘贴文本或导入文件，也可以在Payload Processing里加规则，比如统一转成大写、加前缀后缀。我习惯在Payload Options里先粘贴一行两个值试试水，确认能跑通了再导入完整字典。
5.3 线程、超时和结果筛选：跑得动不等于跑得对
很多人觉得爆破就是把线程调大，越猛越好。实际上线程过高不仅容易把目标打挂，还会导致你自己的网络连接大量超时，最后的结果里真假分不清。更聪明的做法是，先用低线程比如5到10，跑一个50条的小字典，观察响应时间和响应包大小是否稳定。稳定后，再逐步提高线程到20到30，而不是一上来就开200并发。
Intruder的结果标签页里会列出每条请求的状态码、响应长度、响应时间。有几个筛选技巧很实用：
- 状态码：如果正常登录返回200，密码错误返回401，那么瞄准那些状态码明显不同的记录。
- 响应长度：绝大多数错误响应的长度基本一致，一旦出现长度明显偏移的记录，往往就是“挖到宝”的候选。你可以把结果列表按Response length排个序，稍长的可能就是成功的响应。
- 响应内容关键词：在设置里可以添加Grep-Match规则，比如匹配“welcome”“dashboard”“登录成功”这类字符串，Burp会在结果里用高亮显示，更方便一眼找出。
我在实际测试中，更倾向于同时开启“Grep-Match”和“响应长度排序”两个手段，双管齐下确认一个命中结果，而不是只看单一项。因为有时候长度变化是服务器返回了错误页面，状态码200也不代表业务成功。
5.4 爆破前的风险控制与授权边界
写爆破模块这个环节必须提一句：爆破工具本身是双刃剑。它不仅是验证弱口令的合法手段，也很容易被滥用于未经授权的系统。你用自己的Burp爆破一个你没权限的系统，哪怕只是测试，也可能导致目标账户被锁定、被风控、被取证，后果不是“玩坏了再重启”这么简单。
所以我在项目里使用Intruder时，会坚持几条铁律：第一，必须在目标系统所有者明确授权的前提下测试；第二，优先使用小字典、低并发，先跑试点再扩大；第三，如果目标有验证码、短信验证、锁定机制，提前沟通好是否需要绕过或是否允许这种测试；第四，对爆破结果做详细记录，不要只把“成功信息”带走，失败的样本也要留存，便于后面做风控评估。
爆破模块真正有价值的产出，不是“我这台机器跑了多少条请求”，而是你能通过测试结果，给出一个清晰的安全现状判断和加固建议：哪些接口缺少防爆破策略、哪些账号仍在使用弱口令、哪些错误提示泄露了过多信息。这些才是团队真正需要的东西。
最后再分享两个我在实际使用中的小技巧
抓包、改包、重放、爆破这四个维度讲完，你再看Burp Suite就应该有一个比较完整的操作地图了。如果现在就打开软件动手，你会发现很多菜单变得不再陌生，因为每个模块背后都对应着一条实际要解决的问题：怎么让流量流经代理、怎么在流量中转站里篡改内容、怎么重复验证单条请求、怎么自动化扩展参数组合。
我最想强调的一点是：不要一次性把所有功能都学会再动手。先从最简单的HTTP抓包开始，然后加一个HTTPS证书，再试一次改参，再到Repeater里重放，最后再碰Intruder。这条路径每走一步，你都能获得即时反馈，也更容易沉淀出属于你自己的测试节奏。等这个链路跑顺了，再回过头去啃Scan、Decoder、Comparer这些功能，会轻松得多。
还有一个经常被忽略的操作习惯：Burp里的标签页会越堆越多，Repeater的标签页我通常会开好几个，每个标签页负责一类接口，比如登录接口、订单接口、个人信息接口各占一个，测试起来会清晰很多。如果一条请求你已经不再需要，随手关闭标签页，免得最后自己都分不清哪条是哪条。这些小细节用久了你就知道，它们真的能让测试变成一个清爽有序的过程。
