做授权范围内的Web测试时，很多人会遇到登录态跑着跑着就失效，或每次请求都要带动态令牌与CSRF字段，导致Repeater复测、Intruder压测、Scanner审计都被迫中断。BurpSuite的会话保持本质是把登录续期、Cookie与令牌更新、会话有效性检查放到后台自动完成，让后续请求始终带着可用的会话信息，减少手工补票与漏测风险。

　　一、BurpSuite会话保持在哪里设置

　　BurpSuite把会话保持相关的能力统一放在Sessions设置里，包含会话规则、Cookie jar与宏。你先把入口找到，后面写规则时就能把动作与范围组合起来，做到不同域名、不同功能点用不同会话逻辑。

　　1、从统一入口进入Sessions设置

　　在新版界面中，点击【Settings】→【Sessions】即可看到会话相关的所有模块，常用入口是【Sessions】下的【Session handling rules】、【Cookie jar】、【Macros】。

　　2、在Session handling rules里管理会话规则

　　点击【Settings】→【Sessions】→【Session handling rules】，用【Add】新增规则，用【Edit】修改已有规则；规则编辑器分为【Details】与【Scope】两部分，前者写动作，后者限定哪些请求会触发这条规则。

　　3、在Macros里录制与维护登录续期流程

　　点击【Settings】→【Sessions】→【Macros】，在宏编辑器里通过【Add】从【Proxy history】挑选请求组成宏；宏不是现场录屏式操作，而是由历史请求拼出的请求序列，适合拿来做自动登录、刷新令牌、获取CSRF值这类固定流程。

　　4、在Cookie jar里确认Cookie是否被Burp接管

　　点击【Settings】→【Sessions】→【Cookie jar】，查看目标站点的Cookie是否已进入jar；默认情况下Cookie jar会基于【Proxy】流量更新，必要时你再把相关工具的更新来源打开，保证Cookie能持续被刷新进来。

　　5、用Sessions tracer定位规则是否真正生效

　　点击【Settings】→【Sessions】界面里的【Open sessions tracer】，它会按请求记录规则与动作的执行顺序，以及每一步对当前请求做了哪些改动；排查完建议关闭，因为它会带来额外开销。

　　二、BurpSuite会话保持规则怎么写

　　写规则时先想清楚你要保持的到底是什么，是纯Cookie会话、Header里的Bearer令牌，还是每次都变化的CSRF字段。然后把规则拆成两块，Scope限定触发范围，Actions按顺序把Cookie或参数补齐，必要时先验会话再决定是否续期。

　　1、先把Scope限定到需要会话保持的请求上

　　点击【Add】新建规则后切到【Scope】，在【Tools scope】里勾选你要自动处理会话的工具，例如【Repeater】、【Intruder】、手工浏览产生的【Proxy】流量；再用URL范围把域名与路径收窄，避免把登录续期动作误用到无关站点。

　　2、Cookie会话优先用Cookie jar动作实现

　　在【Details】→【Rule actions】点击【Add】，选择【Add cookies from the session handling cookie jar】，配置为更新全部Cookie或仅更新指定Cookie；前提是你先用浏览器走一遍登录流程，让Cookie通过【Proxy】进入Cookie jar，这样规则只负责把jar里的Cookie补到每个请求里。

　　3、会话会过期时加上有效性检查与条件续期

　　在【Rule actions】里添加【Check whether the current session is valid】，让Burp通过指定请求或宏去判断会话是否仍有效，再配置判断条件，例如在响应头、响应体或跳转目标里匹配登录成功或未登录特征；当判定无效时，选择继续执行一个【Run a macro】用来自动重新登录，并把新会话结果更新回后续请求使用的Cookie或参数。

　　4、遇到CSRF或一次性令牌时用宏的参数派生能力

　　先在【Macros】里用【Add】从【Proxy history】挑选获取表单或令牌的请求序列，进入宏编辑器后选中某一步点击【Configure item】，在【Parameter handling】里把动态字段设为【Derive from prior response】，让Burp从前序响应中找到同名参数并提取其值后回填到后续请求；如果令牌不在常规表单或链接里，而是在脚本字符串等位置，使用【Custom parameter locations in response】添加自定义提取位置，再让后续请求引用这个参数名完成回填。

　　5、Header令牌或自定义字段用专门动作写入请求

　　当鉴权信息在Authorization这类头字段里，或需要把token写入某个固定参数时，在【Rule actions】里选【Set a specific header value】或【Set a specific cookie or parameter value】，把字段名与写入位置明确下来；若需要替换请求中的一段字符串，使用【Replace matching part of the request】按匹配规则替换为宏或Cookie jar里得到的新值。

　　三、BurpSuite会话保持如何排查与验证

　　会话保持写完不等于生效，常见问题是Scope没命中、宏取值位置不对、Cookie jar没有更新、有效性判断条件写反。按工具自带的可观测能力逐步验证，能更快定位到底是规则没跑，还是跑了但没改到正确字段。

　　1、先用Sessions tracer确认规则是否命中

　　打开【Open sessions tracer】后发起一次目标请求，检查该请求是否出现在tracer列表里，再逐条展开看执行了哪些规则与动作，以及最终请求中Cookie、参数、Header是否被更新为预期值；如果列表里没有记录，优先回到【Scope】检查工具与URL是否覆盖到该请求。

　　2、在Repeater与Intruder里核对最终发出的请求内容

　　会话规则会在请求发出前改写请求，Repeater与Intruder通常会展示改写后的最终请求，便于你直接看到Cookie或令牌是否已被补齐；若你在Intruder里正好把某个Cookie或参数作为payload位进行测试，Burp会避免规则覆盖该位，防止干扰测试口径。

　　3、宏录制失败或跑偏时回查Proxy history与拦截状态

　　宏来自【Proxy history】，要保证你录制时请求完整且顺序正确；如果你用Burp内置浏览器补录请求，注意拦截开启会影响录制流程，出现选不到或请求缺失时先把拦截关掉再补齐需要的请求。

　　4、扫描场景下留意规则的适用边界

　　如果你依赖Burp的爬行与基于爬行的审计能力，需要注意Scanner在某些扫描模式下会自行管理会话，而不会对这类扫描请求套用一般的会话规则，只有少数动作类型会被例外应用；遇到扫描中途掉线，通常要把续期逻辑放到可被适用的动作里，或调整你的扫描与会话维护方式。

　　总结

　　BurpSuite的会话保持设置入口集中在【Settings】→【Sessions】，先用Cookie jar把会话素材接住，再用Session handling rules把动作与范围写清楚，需要续期就用宏与有效性检查把流程自动化。写完规则后用Sessions tracer与Repeater最终请求校验两步走，基本可以把会话掉线与令牌不更新的问题定位到具体一条规则或一个取值点上。