调试自己维护的网站时，有些请求发出后会先收到一个跳转响应。例如，保存界面偏好后，服务端返回302，同时下发一个Cookie，再让客户端打开预览页。直接看预览页，只能知道页面有没有打开。想确认跳转地址是否正确、偏好值有没有随下一次请求发出，就得把中间的响应和后续请求放在一起看。Burp Suite的Repeater可以逐跳查看，也可以按设定的范围自动跟随。

　　一、BurpSuite怎么跟随重定向

　　单次排查可以在Repeater里保留每一跳的响应。遇到已经确认过的跳转链，再开启自动跟随，减少重复点击。

　　1、手动跟随一条跳转

　　①、在【Proxy】→【HTTP history】中选中自有测试站点的请求，右键选择【Send to Repeater】。

　　②、打开【Repeater】，点击【Send】，在响应区查看状态码和【Location】响应头。

　　③、如果工具栏出现【Follow redirection】，先核对目标地址，再点击该按钮发送下一跳请求。

　　④、如果下一跳仍返回重定向，继续查看本次响应的【Location】，按实际需要逐跳跟随。

　　手动查看时，像/preview这样的相对路径，要结合发出该响应的请求地址来读。遇到多跳流程，可以把每一跳的状态码和目标路径记下来。这样即使页面最后能打开，也能看出中间是否经过了意外的路径。

　　2、设置自动跟随的范围

　　Repeater有项目级设置，也允许单个标签页使用自己的设置。对同一项目中的不同请求，可以按各自的跳转目的地安排跟随方式。

　　①、打开【Settings】→【Tools】→【Repeater】，找到【Redirects】区域。

　　②、在【Follow redirects】中，选择适合当前流程的范围。同域跳转可用【On-site only】，按项目目标范围跟随可用【In-scope only】，需要逐跳查看时可用【Never】。

　　③、选择【In-scope only】时，在【Target】→【Scope】中确认预期的目标地址已纳入范围。

　　④、回到【Repeater】重新发送请求，用【Logger】核对实际发出的请求和返回的响应。

　　二、BurpSuite重定向时怎么携带Cookie

　　跳转地址来自响应里的Location，服务端新下发的Cookie则来自Set-Cookie。Repeater分别控制是否跟随跳转，以及跟随时是否处理这次响应设置的Cookie。

　　1、开启跳转响应的Cookie处理

　　①、进入【Settings】→【Tools】→【Repeater】，在【Redirects】中启用【Process cookies in redirects】。

　　②、在同一区域确认【Follow redirects】允许跟随当前目标，或在收到响应后手动点击【Follow redirection】。

　　③、打开【Logger】，定位下一跳请求，在原始请求头中查看【Cookie】字段。

　　④、返回上一跳响应，核对【Set-Cookie】里的名称和值，确认下一跳发送的是本轮下发的数据。

　　这个选项处理的是跳转响应设置的Cookie。如果一条跳转链经过几个页面，服务端可能在中途更新同名值。排查时，把每条响应和紧接着的请求配对看，比只看首尾两条记录更容易找到变化发生的位置。

　　2、看懂响应头和请求头的写法

　　例如，自有测试站点保存显示偏好后，返回Set-Cookie:view=compact;Path=/preview。其中view=compact是名称和值，`Path=/preview`用来限定发送范围。检查预览页请求时，可以据此确认字段格式和目标路径。

　　①、在【Repeater】的响应区找到【Set-Cookie】，记录其中的【view=compact】和【Path=/preview】。

　　②、在【Logger】中选中发往【/preview】的下一跳请求，查看是否出现【Cookie:view=compact】。

　　③、如果要手动验证这条同站请求，可在【Repeater】的请求头中填写【Cookie:view=compact】，再点击【Send】。已有其他适用的Cookie时，在同一请求头中保留所需的名称和值。

　　3、检查当前标签页是否覆盖项目设置

　　①、在当前【Repeater】标签页点击【Send】旁的设置图标，查看【Follow redirects】和【Process cookies in redirects】。

　　②、如果该标签页已有单独配置，在同一个菜单中把两项一起核对，再发送请求。

　　③、需要恢复项目设置时，选择【Restore global default】，重新查看【Logger】中的下一跳请求。

　　标签页一旦使用单独设置，就会采用该标签页的整套配置。项目设置里已经勾选Cookie处理，当前标签页仍可能按自己的配置发送。遇到两个标签页的表现不一致，可以从这里查起。

　　三、BurpSuite跳转后没有带上Cookie怎么排查

　　先确认下一跳有没有发出，再看那条请求携带了哪些字段。如果浏览器里的结果与Repeater不同，还可以把两边的请求放在一起对照，找出差异出在哪一跳。

　　1、核对跳转有没有发生

　　①、在【Logger】中按请求时间定位这轮操作，确认初始请求后面是否出现了目标路径的请求。

　　②、如果没有后续请求，查看【Location】指向哪里，再检查【Follow redirects】及【Target】下的【Scope】设置。

　　③、如果响应带有【Location】但没有出现跟随按钮，进入【Settings】→【Network】→【HTTP】，核对【Allowed redirect types】中的允许类型。

　　④、如果目标继续跳转，逐条核对【Location】和请求方法，记录从哪一步开始偏离预期。

　　2、对照浏览器和Repeater的请求

　　①、用同一个测试账号在浏览器中走一遍操作，在【Proxy】→【HTTP history】里找到预览页对应的请求。

　　②、从前一跳响应的【Set-Cookie】中检查【Domain】、【Path】和【Secure】，再对照目标的主机、路径及协议。

　　③、在【Logger】中打开Repeater发出的对应请求，对比两边的【Cookie】名称和值，并查看链路中是否有后续响应更新了同名值。

　　浏览器会按Cookie属性决定发送范围。比如服务端把偏好Cookie限定在预览路径，跳转到其他路径时，就不能用“服务端发过这个值”来判断它应该出现。碰到这种差异，保留目标地址和相邻两条报文，往往就能定位是服务端下发范围的问题，还是Repeater的设置有偏差。

　　总结

　　调试重定向时，最终页面的状态码只反映链路末尾的结果。对依赖Cookie的页面，更有价值的记录是服务端在哪一跳下发或更新了值，以及客户端随后把哪个值发到了哪个地址。复现跳转问题时，保留这对请求和响应，交给负责页面或会话逻辑的同事，也更容易说明问题发生的位置。