告别反复填表提交，Burp Suite让验证快一步

在Web安全测试中，发现一次异常后，往往需要再次发送相同请求，确认问题是否还会出现。

对刚开始独立测试的新手来说，最熟悉的办法是回到网页，重新填写条件、点击提交，再从抓包记录中寻找对应结果。一次操作并不复杂，但连续确认几次，重复准备就会占用不少时间。

Burp Suite的Repeater提供了更直接的方式：将已经抓到的请求原样重发，让测试人员减少页面操作，把注意力留给返回结果。

01 / 需要重复的是请求，页面流程可以少走一遍

以企业内部资料检索为例：测试人员进入查询页面，选择所属部门和资料类型，输入关键词，然后点击查询。

假设这次查询意外返回了空列表，需要再确认一次。如果页面保留了全部条件，再次点击查询即可；但如果页面发生跳转、条件被重置，就需要重新完成前面的选择和输入。

此时，测试人员真正想确认的是：刚才那条查询请求再次发出后，服务器会返回什么？

已有请求中已经包含本次提交的查询条件。将它送入Repeater，就能基于这份内容再次发送，无需为了生成相同请求而重新走一遍页面流程。

对查询条件较多、操作路径较长的页面，这种方式能够减少连续验证中的准备步骤。

02 / 保留请求内容，直接再次发送

完成首次抓包后，可以在Proxy → HTTP history中找到需要重复验证的查询请求。先确认请求地址及提交内容，避免选中页面加载时产生的图片、脚本等其他请求。

之后只需要三步：

如果还需要继续确认，可以再次点击Send。Repeater支持重复发送当前请求，并在界面中查看服务器返回的响应。

对新手而言，这也是首次抓包之后一个容易掌握的实际用法：抓到的请求可以直接用于后续测试，无需每次重新从页面生成。

一次准备，继续使用

复用一次已经完成的准备，让下一轮验证从“发送请求”开始。

03 / 省下操作步骤，更集中地观察异常

回到资料检索的场景，两种方式的区别在于：

通过页面重新生成请求：返回查询页、确认筛选条件、提交查询、定位新请求，再查看响应。

通过Repeater复用请求：打开已准备好的请求，点击Send，查看响应。

重复确认的次数越多，省去的页面操作越有意义。测试人员可以将精力集中在同一个问题上：空列表是否再次出现？本轮是否返回了错误信息？异常是否具有重复出现的条件？

这里需要区分的是，请求内容相同，不代表服务器状态始终相同。数据更新、登录失效或一次性令牌，都可能影响重发结果。若返回内容发生变化，仍需结合实际情况分析。

本篇以读取资料的查询请求为例；涉及新增、删除等操作时，重复发送可能再次执行相应动作，需要先明确请求用途。

Burp Suite在这一环节体现的价值很具体：让已有请求继续发挥作用，减少重复进入页面、填写条件和定位请求的步骤，使手动验证更集中。

对于刚完成安装配置和首次抓包的新手，这一步就能把工具使用推进到实际测试中。

这里是慧都科技，欢迎沟通交流，如有任何问题欢迎私信评论~