要弄清楚Burp Suite里面Intruder这个工具该怎样去配置，还有它的攻击速度要是变得很慢，可以从哪些地方试着优化，不能只把眼睛放在并发请求的数量上面，Intruder跑起来的效率，还会被Payload塞在哪些地方、攻击用的类型、字典塞了多少东西、请求之间隔了多长时间、连接是怎么维持的，还有目标服务器返回结果的速度，这些因素一起拖着走，在真正动手配置以前，最好先到Repeater那边，确认一下最基础的请求是能正常返回的，同时也要保证测试的目标已经拿到了清楚的授权，免得把请求本身藏着的问题，错误地当成是Intruder在速度上出了毛病。

许多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复核复现。

由PortSwigger发布的Burp Suite默认会记录代理通道里的HTTP与WebSocket消息，页面资源一多就会出现历史列表刷屏、检索困难、内存占用上升的问题。处理思路可以分两层，第一层先把抓取范围收敛到你确实要测的目标，第二层再用过滤规则把显示与记录分开控制，做到既不漏关键请求，也不被静态资源淹没。

BurpSuite里一个项目文件往往承载了Proxy历史、站点地图、扫描与组织器数据等关键证据链，一旦出现“项目文件打不开”，轻则当天的抓包与记录需要重做，重则历史线索和复测依据丢失。处理这类问题要把思路拆成两步：先让文件“能被正常打开或被识别为可修复”，再把数据“尽可能完整地恢复到可继续使用的新文件”，同时补上备份与存储位置这道保险。

很多人把BurpSuite的CA证书导入后，浏览器仍弹出不安全提示，抓包也时断时续。根因通常不在证书本身，而在于证书导入位置不对、代理未生效、站点启用了更强的安全机制，或是目标应用并不信任用户安装的证书。下面按可复现的排查顺序，把提示来源拆开处理，做到每一步都有明确的验证点。

在排查接口签名、复现偶发请求、验证边界条件时，你经常需要在不改代码的前提下，临时改一改请求头、Cookie、参数或响应内容。围绕“BurpSuite Match and Replace有什么用，BurpSuite Match and Replace规则怎么写”，把它理解成一套可控的流量改写器更准确：先按匹配条件抓住目标流量，再按替换动作把内容改成你想要的样子，并且可以对不同工具链的流量分别生效。