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

　　一、BurpSuite Repeater怎么修改响应包

　　在Repeater界面里，左侧是请求，右侧是响应。一般情况下，你可以在左边修改请求的内容，点一下【Send】之后，再查看右侧出现的响应变化。右侧的响应区域更多是用来查看、搜索、复制和分析返回数据的，并不能直接去左右服务器逻辑，或者改变浏览器最终看到的东西。

　　1、从历史记录把请求送进Repeater

　　先在【Proxy】→【HTTP history】里找出你打算测试的那条请求，对着它右键点击，选择【Send to Repeater】。请求被导入之后，在左侧编辑区里调整URL、参数、Header、Cookie或者消息体，接着再点【Send】，右侧就会显示服务器针对这次新请求返回的最新结果，整个过程很适合反复对参数做微调。

　　2、利用多个标签页对比不同响应

　　Repeater支持同时打开好几个标签页，这样正好拿来比较不同参数组合的效果。比如一个标签里保留原始的Cookie，另一个则把用户ID或权限相关字段给改掉，两个请求分别发出去之后，再仔细比一比它们的状态码、响应正文、返回头以及关键字段存在哪些差异，很快就能看出参数变动到底影响了什么。

　　3、要改浏览器看到的响应得用Proxy

　　假如你的目标并不是单纯看服务器反馈，而是想让浏览器接收到的页面内容变得和服务器实际返回的不一样——例如把某个字段的值替换掉——那就不能在Repeater里死磕，而应该转向【Proxy】→【Intercept】，打开响应拦截。当服务器回复经过Burp时会被先卡住，你可以手动编辑里面的内容，再放行，这时浏览器收到的就是你修改后的响应。Burp Proxy本来就架在浏览器和服务器中间，专门用来监视和调整双方交互的，做这类操作正好对路。

　　4、需要自动替换内容时用Match and Replace

　　如果在测试中反复碰到同一种修改需求，比如每次都想把响应体里的某个字符串批量改掉，或者统一替换Header的某个值，那就可以到【Proxy】→【Match and replace】去添加规则。根据PortSwigger官方文档的描述，Match and replace规则能在消息穿过代理的过程中，自动对HTTP和WebSocket消息执行查找与替换，可以用来改Header、重写响应内容，或者自动更新认证Token，免去了每次手动操作的麻烦。

　　二、BurpSuite Repeater修改后为什么不按预期返回

　　在Repeater里改完请求并发送之后，如果得到的响应和你预想的不太一样，往往不是Burp本身出了故障，而是你单独发出的这条请求所处的环境，与真实浏览器那边发请求时的上下文差得太远。服务器在决定返回什么时，会综合检查Cookie、Token、Header、请求的先后顺序，以及当前会话的状态。

　　1、你改的是请求，而不是响应

　　在Repeater里每次点【Send】，Burp做的事情都是把左侧新构造的请求再次发给服务器，服务器则会重新计算一番再返回一个新响应。你不能在右侧的响应编辑区里手动改掉几行文字，然后就指望服务器下一次能按你改的来。对响应包所做的修改，只在当前这次拦截或转发的过程中起作用，并不会改变服务器本身的业务逻辑。

　　2、会话状态可能早就过期了

　　从Proxy历史记录里找到的那条请求，发出时间或许已经是几分钟甚至更早以前了。等你把它放进Repeater里隔了一阵才去发送时，里面携带的登录会话、CSRF Token、一次性Nonce、时间戳和签名参数，很可能已经完全失效。服务器验出这些信息过期之后，自然不会再返回正常数据，而是直接给一个403禁止访问的提示，或者跳回到登录页面。

　　3、请求里的Header不完整

　　真实浏览器在发请求时，除了请求行和参数，还会悄悄带上很多额外的头信息，比如Origin、Referer、Accept、Content-Type以及完整的Cookie和Authorization等。当请求被复制到Repeater以后，如果不小心漏掉了某个关键的Header，后端就可能走向另一条处理分支，最后返回的结果自然跟在浏览器里看到的截然不同。

　　三、BurpSuite响应修改怎么复核

　　想确认自己做的响应修改是不是真的影响了浏览器的呈现，必须在Proxy这条完整的代理链路中去验证，不能只盯着Repeater窗口。

　　1、先搞清楚自己的修改目标

　　如果目的是简单验证不同参数对服务器响应的影响，用Repeater就足够了；假如目的是让前端页面里显示出那些被篡改过的字段，就必须在Proxy的响应拦截里处理，或者靠Match and Replace规则自动替换，这样修改后的内容才能真正抵达浏览器。

　　2、检查自动替换规则的作用范围

　　在Match and Replace里配置规则的时候，要特别注意规则生效的范围是响应头、响应体还是整条消息，同时，匹配的文本、大小写、是否使用正则表达式，以及返回数据的Content-Type都得对上，否则规则就可能不会触发，自然也不会有替换效果。

　　3、留意响应的压缩与编码

　　现在很多服务器返回的内容都经过了gzip或br压缩，或者前端自己对数据做了加密处理。如果拿到的是一堆压缩后的乱码，直接在它上面做普通的文本查找与替换就很难生效。遇到这种情况，可以尝试在请求里让服务器返回未压缩的原始内容，或者在Burp内部先用解码功能看清楚响应正文的真实模样，再判断适不适合做文本替换。

　　4、从浏览器那边重新触发一次请求

　　当所有规则都设好以后，不要只在Burp里发送就算完事，务必要从配置了代理的浏览器，或者Burp自带的浏览器中，重新去打开对应的页面，重新触发一次操作。因为只有让浏览器真实地发出了请求，经过代理，并在这个过程中被你修改了响应内容之后，你才能确定浏览器最终接收并渲染出来的，到底是不是自己期望的结果，光靠Repeater是说明不了问题的。

　　总结

　　BurpSuite的Repeater模块，主要用来修改并重发请求，从而观察服务器的响应变化，而不是一个可以直接改动浏览器收到内容的工具。如果需要修改返回给浏览器的响应，应当使用Proxy的拦截功能，或者预先配置好Match and Replace规则。发现修改后的结果和预期不符时，要重点去检查登录状态、Token有效期、请求头的完整性、调用顺序、规则的匹配范围以及响应内容的编码方式，这样排查起来才更有方向。