Burp Suite Repeater实战指南：HTTP请求精细调试与渗透测试技巧

1. 项目概述：为什么Repeater是渗透测试的“瑞士军刀”

如果你在安全测试或者Web应用渗透的圈子里待过一阵子，那你肯定绕不开Burp Suite。而Burp Suite里，除了Intruder和Scanner，最常用、最核心的模块，我认为就是Repeater了。很多人把它简单地理解为一个“重放请求”的工具，这其实大大低估了它的价值。在我过去十多年的实战里，Repeater更像是一个精细的“手术台”，所有从Proxy拦截下来的流量，都可以放到这里进行无麻醉的解剖、修改、再观察。无论是验证一个简单的SQL注入点，还是构造复杂的JSON序列化攻击载荷，或者调试一个多步骤的认证流程，Repeater都是那个让你能慢下来、看清楚、试明白的地方。

这次我们不谈那些宏大的攻击框架，就聚焦在这个看似简单却极其强大的Repeater模块上。特别是针对HTTP请求中最核心的GET和POST方法，以及它们衍生出的各种混合场景（比如带文件上传的POST、Content-Type切换等），我会带你走一遍从基础配置到高阶技巧的完整路径。你会发现，一个请求从拦截到成功重放，中间可能藏着十几个需要留意的细节。无论是刚入门的新手，还是想梳理一下知识体系的老手，这篇指南都能让你对Repeater有一个全新的、更深入的认识。我们不止讲“怎么点按钮”，更要讲清楚“为什么这么点”以及“点错了会怎样”。

2. Repeater模块的核心界面与基础操作解析

刚打开Repeater，你可能会觉得界面有点复杂，一堆标签页和按钮。别慌，我们把它拆开来看。一个典型的Repeater窗口主要分为左右两大部分：请求编辑区（Request）和响应展示区（Response）。这构成了最基本的“发送-观察”循环。

2.1 请求编辑区：你的攻击画布

左边这块区域是你施展拳脚的地方。默认情况下，它会显示你从Proxy或者其他模块（比如Target的Site map）发送过来的原始HTTP请求。这里的一切几乎都是可编辑的。

首先是请求行（Request Line），它长这样：GET /api/user?id=1 HTTP/1.1。这里你可以直接修改请求方法（如把GET改成POST）、请求的URI路径以及HTTP协议版本。一个常见的误区是，很多人只改后面的参数，却忘了路径本身也可能存在漏洞，比如路径遍历（../../../etc/passwd）。

紧接着是请求头（Headers）。Burp Suite非常智能地把一些常用头（如Host, User-Agent, Content-Length）用较深的颜色显示，而自定义头则用另一种颜色。你可以任意地添加、删除或修改这些头部字段。这里藏着一个关键点：Content-Type头。当你把请求方法从GET改为POST时，Burp通常不会自动帮你添加或修改这个头。如果你打算发送表单数据（application/x-www-form-urlencoded）或JSON（application/json），你必须手动添加或修改这个头，否则服务器可能无法正确解析你的请求体，直接返回400或415错误。

最后是请求体（Body），对于GET请求，这部分是空的，参数都在URL的问号后面。对于POST请求，这里就是主体内容了。Repeater的请求体编辑器有两种视图：“Pretty”和“Raw”。我强烈建议在大多数情况下使用“Raw”视图，因为“Pretty”视图虽然好看（比如自动格式化JSON），但有时会偷偷修改你的原始数据（比如空格、换行符），导致请求发送出去和你想的不一样，这种隐蔽的差异在测试敏感漏洞时是致命的。

注意：在“Raw”视图下编辑时，务必留意行尾的换行符。HTTP协议要求头部和主体之间用一个空行（即连续的两个回车换行符\r\n\r\n）分隔。在Repeater里，这个空行通常是已经帮你处理好的，但如果你在Raw视图里不小心删掉了它，请求就会变得不合法。

2.2 响应展示区：结果的显微镜

右边是响应展示区。同样，它也有多种视图模式：

• Raw：显示原始的、未经处理的HTTP响应字节。这是最真实的视图，用于查看精确的响应头、响应体以及可能隐藏的特殊字符。
• Headers：只显示响应头，方便你快速查看状态码、Cookie、跳转位置等信息。
• Hex：以十六进制形式显示响应，在分析非文本内容（如图片、二进制数据）或检测不可见字符时非常有用。
• HTML：将响应体渲染为网页。这对于测试跨站脚本（XSS）等需要浏览器解析的漏洞至关重要，因为你可以在Burp内置的浏览器中直接看到攻击是否成功执行。
• Render：与HTML类似，但更侧重于渲染效果。

一个高级技巧是使用“对比”（Compare）功能。你可以将两次请求的响应进行差异对比，Burp会高亮显示增加、删除和修改的内容。这在测试模糊测试（Fuzzing）结果、验证输入是否影响输出时极其高效。比如，你修改了一个参数值，通过对比可以立刻看出返回的JSON数据里哪个字段发生了变化，而不用人肉去盯。

3. GET请求的精细配置与实战技巧

GET请求看似简单，就是把参数放在URL里。但在Repeater中操作GET请求，有很多细节能提升你的测试效率和精度。

3.1 基础参数修改与URL编码

假设你拦截到一个请求：GET /search?keyword=test&page=1 HTTP/1.1。你想测试SQL注入，很自然地把keyword的值改成test'。这里第一个坑就来了：URL编码。

当你直接在Repeater的请求行或参数列表里输入test'时，Burp默认可能不会自动对它进行URL编码。单引号'在URL中是一个特殊字符。如果服务器端没有做好处理，你的单引号可能无法完整到达后端代码。更稳妥的做法是，使用快捷键Ctrl+U（对选中内容进行URL编码）或者右键选择“Convert Selection” -> “URL” -> “URL-encode”。你应该看到keyword=test%27。同理，空格会被编码为%20，等号=是%3D。

反过来，当你收到一个已经被编码的请求时，为了可读性，可以用Ctrl+Shift+U进行URL解码。但切记，在发送前，确保需要编码的特殊字符已被正确编码。一个良好的习惯是，在修改完参数后，眼睛扫一下请求行，看看有没有“裸露”的特殊字符。

3.2 使用Params选项卡进行结构化编辑

对于复杂的GET请求，参数很多，在请求行里直接修改容易出错。这时应该切换到“Params”选项卡。这里Burp会把URL中的参数解析成键值对表格，你可以清晰地添加、删除、修改每一个参数。

这个视图还有一个巨大优势：它可以帮你自动管理URL编码。在表格里输入的值，Burp会在生成最终请求时自动处理编码问题，比你手动在Raw视图里敲更不容易出错。特别是当你需要插入大量特殊字符或Payload时，用Params视图是首选。

3.3 实战场景：自动化参数遍历与状态保持

有时你需要快速遍历一个参数的所有可能值。虽然Intruder更适合大规模爆破，但Repeater也有轻量级的技巧。比如，测试一个ID参数是否存在水平越权：/api/user/profile?id=1001。你手动改成1002、1003去试，很累。

你可以这样做：

1. 在Repeater中发送一次id=1001的请求，确认正常。
2. 然后，不要关闭这个标签页。直接修改id值为1002，再次发送。
3. 关键点来了：注意观察和对比响应。除了看数据内容，更要关注状态码（是否从200变成403？）、响应长度（是否有细微差别？）以及是否有新的Cookie或Token返回。

在这个过程中，会话（Session）的保持是另一个核心。如果这个请求需要认证，你第一次发送时使用的Cookie或Token，在后续的请求中默认会被Repeater沿用。这就是为什么Repeater标签页如此重要——每个标签页都维持着自己独立的“会话状态”。你可以打开多个标签页，分别测试不同用户上下文下的请求，互不干扰。要管理这些会话，可以右键标签页，使用“Send to Repeater (in new tab)”功能，或者使用“Project options” -> “Sessions”来配置更复杂的会话处理规则。

4. POST请求的深度配置与Content-Type的奥秘

POST请求的世界比GET丰富得多，也复杂得多，核心差异就在于请求体（Body）和与之绑定的Content-Type头。

4.1 表单提交：application/x-www-form-urlencoded

这是最常见的POST格式，和GET请求的URL参数类似，只是数据放在了请求体里。格式是key1=value1&key2=value2。在Repeater中处理这种请求非常直观。

当你从Proxy拖一个表单POST请求到Repeater时，Burp通常能正确识别并自动设置好Content-Type: application/x-www-form-urlencoded。你可以在“Params”选项卡的“Body”部分看到这些参数，并以表格形式编辑，非常方便。这里要注意的是，参数值中的特殊字符（如&,=）会被自动编码，无需担心。

一个实战技巧是测试文件上传漏洞。有时上传接口看起来是POST一个表单，但其中一个参数的值可能是文件内容。你可以尝试在参数值中插入恶意字符串（如<?php system($_GET[‘c’]);?>），并将参数名改为看起来像文件的字段名，同时观察服务器的解析错误，这可能暴露出安全漏洞。

4.2 JSON数据交互：application/json

现代Web API大量使用JSON。在Repeater中处理JSON请求，你需要做两件事：

1. 将Content-Type头修改为application/json。
2. 在请求体（Raw视图）中，输入合法的JSON格式数据。

这里有一个巨大的“坑”：JSON的语法要求非常严格。字符串必须用双引号，最后一个元素后不能有逗号。Burp Suite的Repeater不会帮你验证JSON语法。如果你手抖写错了，服务器会返回一个可能是400 Bad Request或者500 Internal Server Error，但错误信息可能很模糊，让你以为是Payload本身的问题，而不是格式问题。

我的建议是：

• 对于复杂的JSON，可以先用外部的JSON格式化工具写好、验证好，再粘贴进来。
• 使用Repeater的“美化”（Pretty）功能时要格外小心。它可以帮助你格式化凌乱的JSON，但同样，只在确认原始数据无误后用于查看，编辑时最好切回Raw视图。
• 在测试JSON注入或参数污染时，可以尝试在JSON字符串值中插入特殊字符，并观察是否需要JSON编码（如将双引号"转义为\"）。

4.3 多部分表单数据：multipart/form-data

当POST请求包含文件上传时，就会使用这种类型。它的Content-Type头看起来像这样：Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW。

boundary是一个随机生成的字符串，用于在请求体中分隔不同的表单字段。在Repeater的Raw视图里，你会看到请求体被这个boundary分割成多个部分，每个部分有自己的头和信息。

手动构造或修改这种请求极具挑战性，因为你必须保证：

1. Content-Type头里的boundary值和请求体里实际使用的分隔符完全一致。
2. 请求体各部分格式完全正确，包括换行符。

因此，对于multipart/form-data类型的请求，最佳实践是永远不要尝试在Raw视图里手动从头构建它。正确的方法是：

1. 使用Proxy拦截一个浏览器正常发出的文件上传请求。
2. 将这个完整的请求发送到Repeater。
3. 在Repeater中，你可以在“Params”选项卡的“Body”部分，以类似表格的形式看到文本字段和文件字段。你可以在这里相对安全地修改文本字段的值，甚至替换文件字段的文件名和内容（内容区域以字节形式显示）。
4. 如果需要彻底更换文件内容，可以先将恶意文件内容用Hex编辑器准备好，然后在这里进行替换。

5. 混合请求与高级场景实战

真实的测试场景往往不是单纯的GET或POST，而是它们的混合或变种。

5.1 GET参数与POST Body共存

有些API设计比较特殊，它可能在URL的查询字符串（GET参数）里传递一些过滤或分页信息，同时在请求体（POST Body）里传递主要的业务数据。例如：POST /api/orders?page=1&size=20 HTTP/1.1， 请求体是一个JSON。

在Repeater中测试这类接口时，你需要两头兼顾。修改URL中的参数可能会影响服务器的路由或预处理逻辑，而修改Body则是核心业务测试。我的策略是，先固定一方，测试另一方。比如，先保持URL参数不变，系统地测试Body中各个字段的边界和注入点；然后再设计几组不同的URL参数，搭配固定的合法Body，测试接口的权限控制或业务逻辑。

5.2 修改请求方法：PUT、DELETE、PATCH等

RESTful API常用到PUT（更新）、DELETE（删除）、PATCH（部分更新）等方法。在Repeater中，你可以直接将请求行中的POST改为PUT或DELETE，并相应地调整请求体和Content-Type头，来测试这些接口。

这里的关键是理解服务器的预期。例如，一个更新用户信息的接口，用PUT可能期望一个完整的用户对象JSON，而PATCH可能只期望传递需要更新的那几个字段。测试越权删除时，只需将GET或POST请求改为DELETE方法，并发送到目标资源端点（如/api/user/123），往往就能快速验证是否存在漏洞。

5.3 处理重定向与跳转

当你发送一个请求后，响应码是302 Found或301 Moved Permanently，并且包含一个Location响应头时，表示服务器要求客户端跳转到另一个URL。

Repeater默认不会自动跟随重定向。这是一个非常重要的安全特性。因为自动跟随重定向可能会让你错过关键信息。比如，一个登录失败后跳转到错误页面的响应，其响应体里可能包含了具体的错误原因（如“用户名不存在”或“密码错误”），这些信息对枚举用户名非常有价值。如果自动跳转了，你就看不到这个中间响应。

你可以通过界面上的“Follow redirection”下拉菜单来控制这一行为：

• Never: 永远不跟随（默认，推荐用于安全测试）。
• On-site only: 仅跟随同一站点的重定向（防止被重定向到外部恶意站点）。
• Always: 总是跟随。

在测试时，我通常先设置为“Never”，分析原始响应。如果需要查看跳转后的最终结果，再手动切换到“Always”或右键响应区域选择“Follow redirection”。

5.4 利用Repeater进行链式请求测试

很多操作是链式的，比如：1. 登录获取Token -> 2. 用Token访问个人资料 -> 3. 用个人资料中的ID去修改信息。

Repeater的多个标签页可以完美支持这种测试：

1. 在第一个标签页完成登录，从响应中复制出Token。
2. 打开第二个标签页，粘贴Token到请求头的Authorization字段，发送获取个人资料的请求，从响应中复制用户ID。
3. 打开第三个标签页，构造更新请求，同时放入Token和用户ID。

为了提升效率，你可以使用Burp的Macros（宏）和Sessions（会话）功能实现自动化。但即便是手动操作，合理利用标签页和复制粘贴，也能高效完成复杂流程的测试。

6. 核心配置选项与性能调优

除了基本的发送请求，Repeater还有一些隐藏的配置能极大影响你的测试体验。

6.1 网络与连接设置

在“Repeater”菜单下的“Repeater options”里，有一些关键设置：

• Connect timeout / Read timeout: 连接和读取超时时间。测试内网或响应慢的应用时，可能需要调大这些值（比如从默认的30秒调到120秒），避免请求因超时被误判为失败。
• Unpack gzip/deflate: 自动解压服务器返回的gzip或deflate压缩的响应体。这个选项必须保持开启，否则你看到的响应是一堆乱码。Burp会自动处理Content-Encoding头。
• Follow redirection: 如前所述，控制重定向行为。

6.2 历史记录与对比功能

Repeater主界面下方有一个“History”面板，它记录了当前标签页所有发送过的请求和响应。这是一个非常有用的调试工具。你可以点击历史记录中的任意一条，快速回滚到那个时间点的请求和响应状态。

结合“Compare”功能，你可以选择历史记录中的两个响应进行差异对比。这在测试输入输出相关性时是神器。例如，你怀疑某个参数控制着返回数据中的某个字段，你可以修改该参数，发送两次请求，然后对比两次的响应，差异处会高亮显示，一目了然。

6.3 性能考量：处理大型请求与响应

当处理包含大文件上传/下载的请求时，Repeater可能会变得缓慢。如果请求体或响应体非常大（比如几十MB），在编辑和渲染时会消耗大量内存。

对于这种情况的建议是：

1. 在“Repeater options”中，可以考虑暂时关闭响应的HTML渲染，只查看Raw或Hex视图。
2. 如果只是需要修改请求头或少量参数，尽量避免在Raw视图里打开整个巨大的请求体。使用Params选项卡进行编辑是更轻量的方式。
3. 对于非常大的响应，可以直接将其保存到文件（右键响应区域选择“Save response to file”），然后用外部工具分析。

7. 常见问题排查与实战避坑指南

即使你对Repeater很熟悉，在实际操作中还是会遇到各种奇怪的问题。下面是我总结的一些典型场景和解决方案。

7.1 请求发送后无响应或连接失败

• 检查目标主机和端口：首先确认请求行中的Host头或绝对URL中的主机地址是否正确。如果是从Proxy拦截的请求，通常没问题。但如果你手动修改了，可能指向了错误的IP或端口。
• 检查Burp的代理状态：确保浏览器或测试工具仍然配置为使用Burp Suite作为代理，并且Burp的Proxy监听器是开启的。Repeater本身不依赖代理设置来发送请求，它直接建立TCP连接。
• 检查网络和防火墙：目标服务器是否可达？本地防火墙或目标服务器的防火墙是否拦截了来自你测试机器的流量？
• SSL/TLS问题：如果目标是HTTPS，Repeater会像浏览器一样处理SSL。但如果目标使用了自签名证书或过时的协议，可能会失败。你可以尝试在浏览器中先访问一下目标，让Burp的CA证书被信任，或者检查Burp的“TLS”设置。

7.2 服务器返回400/415错误状态码

• 400 Bad Request：这是最常见的客户端错误。立刻检查：
  1. 请求格式：HTTP请求行、头、体之间的空行是否完整？在Raw视图下检查。
  2. 头部格式：每个请求头是否以CRLF（\r\n）结尾？Burp通常会自动处理。
  3. JSON/XML语法：如果请求体是JSON或XML，语法是否有错误？少一个括号、多一个逗号都会导致400。使用在线验证器检查。
  4. Content-Length头：如果你修改了请求体的长度，必须同步更新Content-Length头的值为新体的字节数。Burp Suite默认会自动更新这个头，这是一个极其重要的特性。但如果你在Raw视图里直接删除并重写了整个请求行和头，可能会破坏这个机制。最安全的方式是让Burp来管理头部，你只修改Body。
• 415 Unsupported Media Type：这明确指向Content-Type头。服务器不认可你发送的Content-Type。核对API文档，确认服务器期望的类型是application/json、application/x-www-form-urlencoded还是multipart/form-data，并确保请求头中的值完全匹配（包括字符大小写）。

7.3 会话（Session）丢失问题

你用一个已登录的会话Cookie测试一个接口没问题，但过了一会儿再测就返回401未授权了。

• 会话超时：这是最常见的原因。服务器的Session有有效期。你需要重新登录获取新的Cookie。
• Token过期：如果是JWT等Token机制，Token可能有过期时间。需要刷新Token。
• 多标签页干扰：虽然Repeater各标签页会话独立，但如果你在一个标签页进行了登出操作，并且这个操作影响了服务器端的全局会话，那么其他标签页的请求也会失败。理解测试目标的会话管理机制很重要。
• Burp的会话管理：你可以配置Burp的会话管理规则（“Project options” -> “Sessions”），让它自动从响应中提取新的会话Token并更新到后续请求中，这对于处理有复杂会话状态的应用程序非常有用。

7.4 响应乱码或显示不正常

• 压缩问题：确保“Unpack gzip/deflate”选项已开启。
• 字符编码问题：服务器返回的文本可能使用了非UTF-8编码（如GBK）。在响应面板的Raw视图下，你可以尝试右键选择“Change text encoding”来切换不同的编码格式，直到中文等字符正常显示。
• 二进制响应：如果服务器返回的是图片、PDF等二进制文件，在Raw视图下会显示为乱码。这是正常的。你应该使用Hex视图查看，或者直接保存到文件后用对应软件打开。

7.5 高效工作流建议

1. 保持请求历史：不要频繁关闭标签页。每个测试用例一个标签页，并用标签页名称做好标注（双击标签页即可重命名），方便回溯。
2. 善用“Send to Repeater”：从Proxy、Target、Scanner等任何地方，都可以右键请求，选择“Send to Repeater”，这是将流量导入Repeater最快的方式。
3. 组合使用工具：Repeater适合精细调试。当需要大规模参数爆破时，将精心构造好的请求从Repeater右键“Send to Intruder”。当发现一个可疑点需要自动扫描时，可以“Send to Scanner”。
4. 备份原始请求：在对一个请求进行大刀阔斧的修改前，可以先在原始标签页上右键选择“Copy URL”或“Copy as curl command”，将原始请求保存下来，以防改乱后无法恢复。

Repeater模块的深度，远不止点击“Send”按钮那么简单。它要求测试者对HTTP协议有清晰的理解，对目标应用的行为有合理的猜测，并且有耐心去观察和比对每一次微调带来的变化。从最基础的GET参数修改，到复杂的多部分表单构造，再到会话链的跟踪，Repeater始终是那个最可靠、最直接的交互界面。掌握它，就等于握住了手动安全测试中最锋利的那把解剖刀。所有的自动化工具最终都要回到这里来验证和调试，这就是它不可替代的价值所在。