Burp Suite Repeater的使用方法，以及发送请求失败的时候应该怎样处理，在Web接口调试和授权安全测试当中，是会经常遇到的。Repeater这个工具能够对HTTP请求反复进行修改并且重新发送，用来比较参数、请求头、Cookie和请求体发生变化之后，响应结果出现了哪些不同。用的时候，最好先留下一条可以正常返回的原始请求，然后再一项一项地去修改。如果请求发不出去了，就需要把连接失败、身份认证失效、请求格式写错，还是被服务器主动拒绝这几种情况，给区分开来。

　　一、Burp Suite Repeater怎么使用

　　在开始使用Repeater以前，最好先打开浏览器，按照正常的操作方式去访问一次目标功能，拿到一条真实并且可用的请求。如果一上来就完全靠手动去写一整段完整的请求，很容易把Cookie、Content-Type、CSRF令牌还有其他一些必须携带的字段给漏掉，这对后面的排查工作是不太有利的。

　　1、从历史记录选择请求

　　进入【Proxy】→【HTTP history】这个位置，在里面找出准备进行测试的那条请求，先确认清楚请求的方法、目标的地址，还有最初返回的响应，都是正常的。

　　挑选请求的时候，可以优先去找那些能够在浏览器里面跑完一整个业务操作流程的记录，比方说用来查询数据、保存设置，或者是提交一张普通表单的请求。因为原始请求本身是能够成功返回的，这样在后面去改动参数的时候，才比较容易判断出来，响应结果的变化，到底是由哪一次修改所引起的。

　　2、把请求发送到Repeater

　　在选定的那条目标请求上面单击右键，选择【Send to Repeater】这一项，然后再切换到【Repeater】那个页面里面，去查看刚刚生成出来的请求标签页。

　　Repeater会把原来请求的方法、路径、请求头、Cookie连同请求体，全都保留下来。点下Send按钮以后，在响应区域就能够看到状态码、响应头，还有返回的正文。进行测试的时候，每一次动手去改，最好只去改动一个参数，尽量不要一口气改掉太多的东西，那样的话，后面就很难搞清楚到底是哪一项变动，带来了具体的影响。

　　3、保留正常请求作为对照

　　一个比较推荐的做法，是把那条完全没有经过改动的正常请求再复制一份，拿来当成一个用于对比的基线，然后另外开出一个新的标签页，在那个里面去调整参数。等到出现了401、403、500这类状态码，或者发现返回的内容看上去不太对劲的时候，就可以马上把那条基线请求拿出来再发送一次，看一看问题是出在自己刚才的修改上面，还是说登录的状态、网络的环境，又或者是服务器本身的状态，已经和原来不一样了。

　　二、Burp Suite Repeater发送请求失败怎么办

　　在Repeater里面发送请求失败了，并不一定就是目标接口本身出了毛病。域名、端口、协议类型、代理的设置、TLS的连接情况，还有当前的登录状态，这几样里面只要有一个地方没有弄对，都可能造成请求超时、连接被断开，或者是服务器直接拒绝。

　　1、检查目标主机、端口和协议

　　先去看一下Repeater标签页当中显示的目标信息，把域名、端口，以及用的是HTTP还是HTTPS，跟浏览器真正访问的时候所用的地址核对一下，看一看是不是一致的。如果目标实际上用的是HTTPS，自己却按HTTP的方式去连接，就很有可能出现连接中断或者TLS握手失败的情况；端口要是填错了，也可能直接就超时了，或者是收到拒绝连接的回应。每次手动复制过请求、改动过Host，或者是把请求导入进来之后，都最好重新回过头去，把目标信息再核实一遍。

　　2、检查网络代理和TLS配置

　　进到【Settings】→【Network】→【Connections】里面，去检查一下，是不是不小心配上了错误的上游代理、SOCKS代理，或者是连接的超时时间设得不合适。

　　如果公司的网络规定了一定要通过指定的代理才能访问到目标，那么Burp这一端也同样需要把正确的代理信息给填上。遇到TLS握手失败、缺少客户端证书，或者是证书链出现异常的时候，还要再去检查跟TLS有关的那些配置。对于那些要求做双向认证的接口，要是没有把对应的客户端证书提供上去，Repeater这边是很可能连一个完整的连接都建立不起来的。

　　3、检查请求格式和登录状态

　　当请求已经能够顺利连接到服务器，但收到的回应却是400、401、403，又或者直接被转到了登录页面，这种时候，就需要去检查Host、Content-Type、Authorization、Cookie以及CSRF令牌这些字段，看看它们是不是还处在有效期内。登录的会话一旦过期了，即便请求的内容没有任何变化，也很可能没有办法再接着执行之前的业务操作了。另外，在对JSON或者表单形式的请求体做过修改之后，还要再去确认一下格式是不是正确、字段的名字有没有写错、请求的方法是不是合适，这个时候，可以重新从浏览器那边抓取一条能够正常使用的请求，拿来跟当前的版本做一个比对。

　　三、Burp Suite Repeater请求异常怎么进一步定位

　　如果那些基础的配置看上去并没有发现什么明显的问题，那就可以根据实际表现出来的现象，把排查的范围再缩小一些。连接超时、TLS相关的错误、完全没有响应，还有返回了业务层面的错误码，这几种不同的表现，它们对应的排查方向，是有差别的。

　　1、查看事件日志

　　把【Event log】打开，看一看在发送请求的那个时候，有没有记录下DNS解析没成功、连接超时、代理认证没有通过、TLS握手失败了，或者是证书报错这一类的信息。

　　假如事件日志已经显示出问题发生在连接层，也就是说请求根本还没有发出去，那就不需要再接着去调整请求的参数了，而是应该先去把网络、代理或者TLS这些方面的问题给处理好。只有在连接能够顺利建立起来之后，再去检查请求头和请求体，这样做才会有实际的意义。

　　2、用简单请求交叉验证

　　可以另外找一条同样是指向这个目标的简单GET请求，把它也发到Repeater里面去测试一下。如果连这条结构很简单的请求也一样失败了，那就说明问题更可能是出在域名、端口、网络连接或者是TLS上面；要是这条简单的请求能够成功返回，偏偏只有特定的那一个接口不行，那么重点就应该放到检查那个接口自己的请求头、认证信息、请求体，还有业务相关的参数上面了。

　　3、确认动态字段是否过期

　　有一部分接口会去校验时间戳、一次性使用的令牌、请求的签名、客户端的证书，或者是某个特定来源的信息。当请求从浏览器被转移到Repeater之后，这些具有时效性的动态字段，很可能已经超过了有效期限，这样一来请求也就会被拒绝了。遇到这种情况，比较合理的做法是重新按照系统的正常操作流程，去拿到一条全新的有效请求，而不是继续对着那条早就过期了的内容，反复去点发送。

　　总结

　　关于Burp Suite Repeater的使用方法，以及发送请求失败之后的排查思路，比较关键的一步是先想办法从HTTP历史记录当中拿到一条正常的请求，然后再逐项去修改参数，同时对比响应前后的变化。一旦发送失败了，可以照着目标地址、端口与协议、网络代理、TLS配置、登录状态还有请求格式这样一个顺序，逐项进行检查。再配合上查看事件日志和用简单请求进行交叉验证的手段，就能比较快地判断出问题是出在连接层、认证层，还是业务的接口层，这样也就避免了在那里一直不停点击Send，却总是找不到具体的原因。