在做Web安全测试的时候，如果一开始没有把范围设定好，浏览器自动加载的那些广告脚本、统计代码、字体、图片，还有发给第三方接口的请求，全都会混进Burp的记录里面。所以，弄清楚Burp Suite的Scope到底该怎样去设置，关键就在于告诉Burp，哪些URL和哪些主机，才是我们这次真正要测的目标。按照官方文档给出的说法，Target Scope这个功能就是专门拿来划定当前项目里需要测试的URL和主机的，有了它，后面过滤浏览器和其他站点产生的那些杂音，就会方便很多。

在进行接口测试、寻找系统漏洞或者重新加载登录状态的时候，经常会碰到这个功能怎么用以及规则为什么没反应的问题。这个功能表面上看起来好像只是把文字换掉，但是其实里面包含了很多东西，比如请求的发送方向、服务器返回的方向、匹配的具体位置、正则表达式是不是写对了，还有就是代理流量有没有真的走软件通过。如果规则写得对，软件就可以自动帮我们把头信息、Cookie、数据主体、返回内容都改掉；要是规则写错了，就会发现虽然把功能勾选上了，但是在抓包的记录里却一点变化都没有。

在授权测试、接口参数验证、登录逻辑排查，还有输入边界检查这些工作里面，经常会碰到Intruder的位置要怎么去标记，还有它的有效载荷，又要怎么去组合的问题，Intruder它最核心的思路，是把一条HTTP的请求，当成一个最基础的模板，然后，在提前指定好的那几个位置上，把各种各样的有效载荷给替换进去，最后再去看一看，服务器返回来的响应，有什么不一样的地方；按照官方文档的说明，有效载荷要放进去的位置，是用一对特殊的符号给包起来的，而攻击的类型，就决定了这些有效载荷，到底是怎么被分配到不同位置上去的，使用这个功能的时候，一定要把它限制在自己有权限去测试的那些系统里面，可千万别把它当成一个可以随便去压测，或者是撞库的工具来用。

在Burp Suite里做项目时，很多人会把项目文件和项目配置当成同一件事，结果前面明明已经导出了配置，后面换一台机器或者换一个项目时，却不知道该从哪里重新接进去。PortSwigger官方现在把这两层分得很清楚。项目文件用来保存当前项目的数据和项目级设置，配置文件则是JSON格式的设置集合，可以单独导入、导出和重复加载。也就是说，真正想复用的通常不是整个项目，而是配置本身，所以导入和复用时要先分清你拿在手里的到底是project file还是configuration file。

在Burp Suite里用Decoder，看起来像是把一段编码内容丢进去再点一次解码就结束了，但实际使用里最常见的问题不是不会点，而是数据本身有多层编码、截断、压缩、混合格式，或者当前选择的解码方式根本和原始数据不匹配。PortSwigger官方现在把Decoder的定位说得很明确，它既支持手动解码，也支持自动识别并解码可识别的格式，比如URL编码；同时，Inspector也会在很多场景里自动解码选中的数据。所以真正高效的做法不是只守着一个窗口，而是先分清数据是不是“Burp能自动识别的格式”，再决定是用Decoder手动拆，还是借Inspector先看一轮。

Burp Suite Repeater的使用方法，以及发送请求失败的时候应该怎样处理，在Web接口调试和授权安全测试当中，是会经常遇到的。Repeater这个工具能够对HTTP请求反复进行修改并且重新发送，用来比较参数、请求头、Cookie和请求体发生变化之后，响应结果出现了哪些不同。用的时候，最好先留下一条可以正常返回的原始请求，然后再一项一项地去修改。如果请求发不出去了，就需要把连接失败、身份认证失效、请求格式写错，还是被服务器主动拒绝这几种情况，给区分开来。

做接口测试时，很多人习惯把请求丢进BurpSuite的Repeater里反复修改参数，但这里容易产生一个误解：Repeater的主要作用，其实是让你编辑并重发请求，然后去观察服务器返回的响应，而不是一个可以“改动服务器返回内容再放行给浏览器”的工具。按照Burp官方文档的说明，Repeater专门用来反复修改、发送HTTP或WebSocket消息，从而分析应用程序给出的响应。如果真正需要去修改经过浏览器接收的响应数据，通常要用Proxy模块拦截响应，或者设置Match and Replace规则来搞定。

在企业内网、要经过代理网关，或者处于测试用的隔离环境里，BurpSuite没办法直接连到目标网站的时候，就需要去配好上游代理。很多人在问BurpSuite里面怎么配置上游代理，以及配完之后如果认证一直失败该怎么排查，这里面最关键的一点，是得把“浏览器到Burp”、“Burp到上游代理”、“上游代理到目标站点”这三段链路分开来看清楚，如果前一段走不通，Burp就根本抓不到任何流量；要是后一段卡住了，Burp虽然能把请求抓到，但目标站点那边却访问失败。

在扫描、实时审计还有攻击测试的时候，资源池要怎么配置，以及它的并发数跑起来不太稳，碰到这种情况，主要得先分清楚当前跑的到底是扫描器、实时审计，还是攻击任务，Burp Suite里的资源池，作用是让好几个任务共享同一套网络资源配额，用它来控制同一时间发出去的请求数量，还有请求往外发的速度，如果没有手动去选一个资源池，扫描任务就会自己去用系统默认的那个，这个资源池主要是给扫描和实时审计这类任务用的，对于被动爬取那类任务，它并不适用。

在站点测试的初期，有一个情况是挺常见的，就是浏览器只要一走Burp的代理去访问页面，Burp就会一刻不停地，把抓到的域名、目录、文件，还有带参数的请求，全给放进站点地图里面去，按照官方的文档说明，站点地图这个东西，就是用来展示Burp在探索目标应用的时候，所收集到的那些信息的，并且，它还支持在按地址去看的视图，和按爬虫路径去看的视图之间，来回切换。

许多Web系统都会在后台使用SessionID、JWT、CSRF Token或者一次性链接参数来保护用户会话和接口安全，但这些自动生成的标识符并不一定就真的可靠，里面有时会暗藏一些能被猜出来的规律。BurpSuite里的Sequencer工具，就是专门用来检测这类令牌的随机性和不可预测性的，它能帮我们判断攻击者是不是有可能通过规律猜测、重放旧数据或者暴力穷举的方式，伪造出一个有效的令牌。这里得先说明白，Sequencer本身不是一个直接拿来攻击的安全漏洞利用工具，它更像是一个统计分析的帮手，所以我们不能光看它给出的表面结论，还需要把信息熵、字符分布、二进制位分布以及实际的业务逻辑绑在一起，才能得出比较全面的判断。

Bambda这个东西，它本质上就是一种可以直接在Burp Suite界面里面跑的Java脚本，用来按照你自己的测试习惯，去扩展过滤、匹配、展示还有处理的逻辑，它比较适合用在像HTTP历史记录的筛选、WebSocket记录的筛选、自定义列，还有匹配替换规则这一类的场景里面。

在站点测试的时候，WebSocket消息要怎么去抓，还有明明操作已经发生了，可记录就是不显示出来，碰到这种情况，比较常见的排查顺序是，先去看一看代理这条链路，它到底有没有经过Burp，然后再去检查一下WebSocket的历史记录，是不是被什么东西给过滤掉了，按照Burp官方文档的说法，WebSocket的记录，是被放在【代理】这个标签下面的【WebSockets历史记录】里面去查看的，这个东西可以用来观察、拦截，还有修改浏览器和服务器之间，通过WebSocket发来发去的那些通信内容。

在Burp Suite里，宏本质上不是“录屏回放”，而是一组从Proxy历史记录里挑出来、按顺序执行的HTTP请求。PortSwigger官方文档写得很直接，宏通常用来处理登录、会话恢复和令牌更新这类需要重复走一遍的流程；而真正让宏在测试里自动生效的，不是宏本身，而是后面的Session handling rule。也就是说，先把宏录对，再把规则挂对，登录流程复用才会稳。

在授权测试场景里，BurpSuite做手工验证时，常见痛点不是抓不到包，而是请求改完要回放很多次，列表一多就容易漏看关键差异。更顺的做法是先用Repeater把请求改到可复现，再用Repeater的分组发送把一组请求批量回放，等基线响应稳定后，再把同一条请求送进Intruder做参数变异，把异常响应筛出来，最后回到Repeater复核复现。

进行手机软件接口数据检查、移动端网页登录调试或者核对请求参数的时候，经常会碰见BurpSuite怎么抓手机流量，以及BurpSuite手机证书安装后为什么还是抓不到这两个让人头疼的问题，其实手机抓包的工作并不是只把一个证书装上就能大功告成，这当中至少要让三个基础条件同时成立才行。

在Web应用安全测试里面，经常会碰到这样的问题，就是BurpSuite扫描器的检查项，到底要怎么去选，还有扫描完了以后，那一堆结果，又要怎么去把重点给筛出来，我们不能以为，把扫描器打开，让它全扫一遍，这件事就算做完了，如果检查项选得太宽，扫描花的时间就会变得很长，出来的结果里面，也会混进去很多价值不高的信息；可要是选得太窄了呢，又很容易漏掉一些接口、参数，还有那些需要登录以后，才能看到的业务入口，根据PortSwigger的文档，Burp扫描器在审计阶段，是通过被动检查、主动检查，还有对JavaScript的分析，来找出问题的，而那些审计方面的设置，也可以帮助我们在覆盖的范围和扫描的速度之间，找到一个平衡。

Burp Suite里的Comparer，本质上就是一个专门做可视化差异对比的小工具。PortSwigger官方文档写得很直接，它可以拿来比较任意两段数据，最常见的用法就是对比两条请求或两条响应，快速找出那些肉眼不容易一眼看出来的细微变化。真正用顺以后，它特别适合拿来比登录前后响应、不同参数下的请求差异，或者同一接口在不同权限下返回内容的变化。

BurpSuite里改了请求但服务器侧看起来没变化，通常不是编辑框没保存，而是你改的那一条并没有真正被转发出去，或者被拦截规则放行了没有停下来，又或者被自动规则二次改写覆盖。按下面顺序把流量是否经过、拦截总开关、拦截规则组合顺序、自动改写规则执行顺序逐个核对，问题一般能在十分钟内收敛到具体开关与具体规则上。

做Web测试时，如果站点或客户端默认走HTTP/2，你在BurpSuite里却看不到请求体、响应体，甚至HTTP history里没有任何条目，往往会让排查方向跑偏。处理这类问题要先确认流量是否真的进了代理链路，再把HTTP/2相关的入站与出站开关分别核对清楚，最后用协议显示位确认每条请求实际用的版本，避免“看起来像没数据”其实只是展示口径不同。