登录接口返回了Cookie，后续请求也一直携带它，但这并不代表安全属性已经配置完整。有时登录响应带有标志，刷新会话时却又被另一条响应覆盖。BurpSuite怎么检查Cookie安全属性BurpSuite Cookie缺少安全标志如何验证，需要从设置Cookie的响应查起，再观察浏览器的实际行为，不能只看请求中的Cookie头。

在Web测试过程中，经常需要临时修改请求或响应中的某些内容，例如替换请求头、调整参数值、修改Cookie或者观察不同输入下的返回结果。Burp Suite中的Match and Replace可以自动完成这些重复修改操作，避免每次都手动编辑请求。不过实际使用时，比较容易遇到规则已经添加，但请求内容没有变化的情况。原因通常和规则作用范围、匹配位置、正则表达式以及启用状态有关。配置时先明确需要修改的对象，再设置匹配条件，后续排查会更方便。

Burp Suite拦截HTTPS流量时，会为访问的站点动态生成TLS证书，再由Burp自己的CA证书完成签名。外部浏览器如果没有信任这张CA证书，就会把Burp生成的站点证书判断为不可信。处理“BurpSuite怎么导入CA证书，BurpSuite CA证书安装后HTTPS仍提示错误如何处理”时，除了确认CA已经安装，还要检查浏览器代理、证书信任范围以及当前Burp实例使用的CA是否一致。

Burp Suite中的Target Scope用于界定当前项目真正需要关注的主机和URL范围。配置Scope之后，Burp的Site map、Proxy、Scanner等工具可以根据范围采用不同的显示、记录或处理策略。不过，Scope本身并不等同于“禁止所有范围外流量经过代理”，因此仍然看到第三方统计、CDN、图片资源或其他域名请求并不一定代表配置失败。围绕“BurpSuite怎么设置Target Scope，BurpSuite Scope配置后仍抓到无关请求如何调整”，需要把目标范围、历史记录过滤和Proxy拦截规则分别设置清楚。

要弄清楚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复核复现。