Burp Repeater实战指南：从请求重放到Web漏洞深度挖掘

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

如果你刚接触Web安全测试，或者已经用了一段时间Burp Suite，但总觉得Repeater这个工具就是简单地“重放”一下请求，那可能就错过了它最核心的价值。在我过去几年的渗透测试和漏洞挖掘经历里，Burp Repeater从来都不是一个简单的“回放按钮”，而是一个功能强大的交互式调试与漏洞验证平台。它允许你像外科手术一样，对HTTP/HTTPS请求进行精细的解剖、修改和反复测试，直到找到那个能让应用“开口说话”的关键参数。

简单来说，Burp Repeater就是一个手动、可控的请求发送器。你把从Proxy（代理）或者其他模块（比如Scanner、Intruder）捕获到的请求，发送到Repeater，然后就可以在一个独立的界面里，对这个请求进行任意次数的修改和重发，并实时观察服务器的响应。这个过程，我们称之为“请求重放”。但它的意义远不止于此。真正的价值在于“重放”之后的“初探”——通过修改请求中的特定部分（如参数值、请求头、请求体），结合对服务器响应的分析，来探测应用是否存在逻辑缺陷、输入验证绕过、信息泄露等潜在漏洞。

举个例子，你在一个登录表单发现了一个名为userid的参数，尝试输入1'（一个单引号）后，页面返回了数据库错误信息。这个瞬间，漏洞的“苗头”就出现了。但这是SQL注入吗？是哪一种类型？如何构造有效的Payload来获取数据？这些问题，都需要在Repeater里，通过一次次精心设计的请求和响应分析来解答。从发现异常响应，到构造出能读取数据库版本、表名、字段名的完整注入语句，整个过程几乎都可以在Repeater中完成。它让你能聚焦于单个请求的细微变化，是理解漏洞原理、验证POC（概念验证代码）最直接、最高效的沙盒。

所以，这个实战演练的目标很明确：不止于学会点击“Send”按钮，而是要掌握如何利用Burp Repeater，从一个模糊的异常点出发，通过系统的测试方法，初步验证和探索常见Web漏洞的存在性与可利用性。无论你是安全研究人员、渗透测试工程师，还是对Web安全感兴趣的开发者，熟练使用Repeater都是你工具箱里不可或缺的一项核心技能。

2. 核心思路与工具定位：Repeater在渗透测试工作流中的角色

要玩转Repeater，首先得清楚它在整个Burp Suite乃至渗透测试流程中扮演什么角色。Burp Suite是一个集成平台，各个模块各司其职，又相互协作。理解这种协作关系，能让你在遇到问题时，快速选择正确的工具。

2.1 Burp Suite模块协作视图

我们可以把一次完整的手动测试想象成一次“狩猎”：

1. Proxy（代理）：这是你的“侦察兵”和“陷阱布置者”。所有浏览器流量都经过它，让你能捕获到应用产生的每一个请求。这是你获取“测试样本”的主要来源。
2. Repeater（中继器/重放器）：这是你的“实验室”和“手术台”。你把Proxy抓到的可疑请求送到这里，进行详细的、反复的解剖和实验。在这里，你验证猜想，构造Payload，观察细微的响应差异。
3. Intruder（入侵者）：这是你的“自动化攻击集群”。当你通过Repeater确认了某个参数存在漏洞（比如一个可爆破的登录点），并且需要系统性地尝试大量Payload（如字典爆破、模糊测试）时，就轮到Intruder上场了。它接管了重复性的批量测试工作。
4. Scanner（扫描器）：这是你的“自动化侦察机”。它可以对目标进行主动扫描，发现一些常见的、模式化的漏洞。但Scanner的结果往往需要人工在Repeater中进行复核和深入验证，以排除误报或挖掘更深层的利用链。
5. Decoder（解码器）&Comparer（对比器）：这些是Repeater的“辅助工具”。Decoder帮你快速对数据进行编码（如URL、Base64、HTML）或解码，方便构造Payload。Comparer则能高亮显示两次响应之间的差异，对于盲注、条件竞争等需要对比响应细微变化的漏洞测试至关重要。

Repeater的核心定位就是“深度分析”和“精准验证”。它不适合做海量请求的爆破（那是Intruder的活），也不适合做广度的漏洞发现（那是Scanner的活）。它的强项在于，给你一个“慢镜头”和“显微镜”，让你能对单个攻击向量进行极致深入的探究。

2.2 实战工作流：从捕获到验证

一个典型的使用Repeater进行漏洞初探的工作流如下：

1. 信息收集与浏览：配置好浏览器和Burp Proxy，正常浏览目标Web应用的所有功能。这时，Proxy的历史记录里会积累大量请求。
2. 筛选与捕获可疑点：在Proxy的HTTP history中，根据经验筛选可疑请求。例如：
   • 所有带参数的GET/POST请求（特别是搜索、登录、文件上传、个人资料修改）。
   • 响应中带有明显错误信息的请求（如SQL错误、堆栈跟踪）。
   • 执行了敏感操作（如支付、添加管理员）的请求。
3. 发送至Repeater：右键点击选中的请求，选择Send to Repeater。这个请求就被复制到了Repeater模块的一个独立标签页中。
4. 请求分析与修改：在Repeater界面，你可以完整地看到请求的原始格式。这时，你需要：
   • 理解请求结构：方法是GET还是POST？Content-Type是什么？参数是放在URL里（Query String）还是请求体里（Body）？有没有特殊的请求头（如X-Forwarded-For,Authorization）？
   • 定位测试点：确定你要修改哪里。通常是最可能由用户输入控制的参数，如id、username、filename、json字段等。
5. 构造Payload并重放：修改参数值，填入你的测试Payload。例如，对于SQL注入，可能是1' AND '1'='1和1' AND '1'='2；对于XSS，可能是 ``。然后点击Send按钮。
6. 分析响应：这是最关键的一步。仔细查看服务器返回的响应。
   • 状态码：200成功？403禁止？500服务器错误？404未找到？状态码的变化能提供第一层线索。
   • 响应体：页面内容是否变化？是否出现了错误信息？是否执行了你的Payload（如弹窗）？长度是否显著不同？
   • 响应时间：对于基于时间的盲注，响应时间的差异（如延迟5秒）是判断漏洞存在与否的核心依据。
7. 迭代测试：根据上一次的响应，调整你的Payload，再次发送。这个过程可能会重复几十次甚至上百次，直到你能够稳定地触发预期的漏洞行为（如获取数据、执行命令）。
8. 漏洞确认与深化：在Repeater中初步验证漏洞存在后，你可能会使用Intruder进行自动化利用（如爆破数据库名），或者进一步在Repeater中手动构造更复杂的利用链。

注意：在整个过程中，保持请求的“上下文”非常重要。有些应用需要维护会话（Session），这意味着你的请求中必须包含有效的Cookie或Token。在Repeater中，这些信息通常会自动从原始请求中带过来，但如果测试过程中会话过期，你需要手动更新。

3. Repeater界面详解与高效操作技巧

工欲善其事，必先利其器。很多人打开Repeater就直接改参数点发送，其实界面上有很多提升效率的细节功能。我们来彻底拆解一下Repeater的界面。

3.1 核心界面分区

一个典型的Repeater标签页分为左右两大部分：请求编辑区（Request）和响应查看区（Response）。

左侧 - 请求编辑区：

• 地址栏：显示目标主机和端口。你可以直接在这里修改，用于快速切换测试目标（比如从正式环境切换到测试环境）。
• 请求方法下拉框：可以快速在GET、POST、PUT、DELETE等方法间切换。这在测试HTTP方法覆盖时很有用。
• “Go”按钮：点击后，会基于当前请求内容，在浏览器中打开这个请求。方便你直接查看请求在正常浏览器中的渲染效果。
• “Cancel”按钮：取消当前正在进行的请求。
• “Send”按钮：发送当前编辑好的请求。
• 请求内容编辑窗口：这是主要工作区。它以纯文本形式展示HTTP请求。你可以任意修改其中的任何部分。
  • Raw标签：原始格式，最常用。你可以看到完整的请求行、请求头和请求体。
  • Params标签：如果请求是application/x-www-form-urlencoded格式，这里会以表格形式列出所有参数，方便修改。对于JSON格式，有时也会有解析。
  • Headers标签：单独列出请求头，可以方便地添加、删除或修改头信息。
  • Hex标签：十六进制视图，在修改二进制文件上传等场景时可能用到。

右侧 - 响应查看区：

• 状态信息：显示响应状态码、响应时间、响应长度。响应长度是盲注测试中一个极其重要的指标。
• 响应内容查看窗口：
  • Raw标签：原始响应，包括响应头和响应体。
  • Headers标签：只查看响应头。
  • Hex标签：十六进制格式的响应。
  • HTML/Render标签：将响应体渲染为HTML页面。对于XSS测试，如果Payload成功，你可能会在这里直接看到弹窗。但要注意，由于安全限制，某些JavaScript可能不会在Render标签中执行，最终确认仍需结合原始响应或浏览器测试。
• 历史记录：在界面的最下方或侧边，有一个历史记录面板。你每次点击Send，当前的请求和响应都会作为一个历史项保存下来。你可以点击任意历史项快速回溯，这对于对比不同Payload的响应差异至关重要。

3.2 提升效率的实战技巧

1. 使用多个Repeater标签页：面对一个复杂的功能点，我习惯同时打开多个Repeater标签页。比如，一个标签页测试正常逻辑，一个标签页测试SQL注入，另一个测试XSS。这样可以避免来回修改同一个请求，也能方便地对比不同攻击向量的响应。右键请求选择Send to Repeater时，可以选择发送到新标签页或现有标签页。

2. 活用历史记录与Comparer：当你测试盲注时，响应可能就几个字符的差别。肉眼很难分辨。这时，不要只盯着看。将你认为“成功”和“失败”的两次请求的响应，分别右键选择Send to Comparer(Response)。在Comparer模块中，使用Words或Bytes对比模式，它能清晰地高亮出差异部分，一目了然。

3. 集成Decoder进行快速编码：在构造Payload时，经常需要URL编码、Base64编码等。不必离开Repeater。选中需要编码的文本，右键选择Send to Decoder。在Decoder模块处理完后，再复制回Repeater。或者，更直接的方式是，在Repeater的请求编辑区直接右键，也有Convert selection的选项，可以进行常见的编码解码操作。

4. 管理请求头：有些测试需要添加或修改特定的请求头。例如，测试HTTP方法覆盖时添加X-HTTP-Method-Override: PUT；测试JSON注入时，确保Content-Type: application/json；测试缓存投毒时，修改X-Forwarded-Host。在Headers标签下操作非常方便。

5. 关注响应时间：在测试基于时间的盲注（Time-based Blind SQLi）或命令注入（Command Injection）时，响应时间（Response timer）是唯一的判断依据。在发送一个包含SLEEP(5)或ping -c 5 127.0.0.1的Payload后，如果响应时间从几十毫秒变成了5秒多，那基本可以断定漏洞存在。Burp的响应时间显示是足够精确的。

6. 使用“Go”功能进行上下文测试：有些漏洞的触发需要完整的页面上下文，比如DOM型XSS，或者某些依赖前端JavaScript处理的逻辑漏洞。在Repeater中修改请求后，点击Go按钮，Burp会用内置的浏览器引擎（或配置的外部浏览器）打开这个请求，让你看到在真实浏览器环境下的效果，这对于验证客户端漏洞非常有用。

4. 实战演练：利用Repeater初探四大常见Web漏洞

理论说再多，不如动手练一遍。下面我们以四个最常见的漏洞类型为例，演示如何从捕获请求开始，在Repeater中完成漏洞的初步探测和验证。为了模拟真实环境，我会假设一些常见的服务器响应场景。

4.1 案例一：SQL注入漏洞的探测与验证

场景：在一个用户查询页面，URL是http://test.com/user.php?id=1，页面显示了用户ID为1的信息。

步骤1：捕获与发送

1. 浏览器访问上述URL，Burp Proxy会捕获到请求：GET /user.php?id=1 HTTP/1.1。
2. 在Proxy历史中，右键该请求，Send to Repeater。

步骤2：基础探测（判断注入点类型）在Repeater的请求编辑区，我们修改id参数的值。

• 测试1：数字型注入探测
  • 原始请求：id=1
  • 修改为：id=1 AND 1=1（逻辑永真）
  • 修改为：id=1 AND 1=2（逻辑永假）
  • 观察响应：如果“AND 1=1”返回正常页面（与id=1相同），而“AND 1=2”返回异常（空页面、错误或与id=999类似），则极可能存在数字型注入。因为1 AND 1=2等价于1 AND False，整个条件为假，可能导致查询无结果。
• 测试2：字符型注入探测
  • 如果参数是字符串，比如name=admin，测试方法类似，但要考虑引号闭合。
  • 修改为：name=admin' AND '1'='1（闭合原引号，并添加永真条件）
  • 修改为：name=admin' AND '1'='2（永假条件）
  • 观察响应：同样对比两者差异。此外，可以单独测试一个引号：name=admin'。如果返回数据库错误（如MySQL的You have an error in your SQL syntax），这是字符型注入的强信号。

步骤3：信息获取验证（Union联合查询）假设通过步骤2确认存在数字型注入，且字段数可测（通过order by，此步骤略）。我们尝试联合查询获取数据库版本。

1. 构造Payload：id=-1 UNION SELECT 1, version(), 3, 4 --
   • id=-1确保原查询无结果，使得Union查询的结果能显示出来。
   • version()是获取数据库版本的函数（MySQL）。
   • --是注释符，用于注释掉原查询后面的部分，避免语法错误。
2. 点击Send。
3. 分析响应：在响应体中搜索“5.7.32”、“10.4.17-MariaDB”之类的版本字符串。如果找到了，那么不仅证明了注入存在，还证明了可以通过注入点提取信息。你可以在Repeater中继续修改Union查询，尝试database()（当前数据库名）、user()（当前用户）等。

实操心得：Union注入的成功与否，很大程度上取决于前端页面显示哪个字段。你需要通过反复测试，确定version()放在SELECT后的第几个位置时，其返回值会显示在页面上。这个过程就是在Repeater中不断调整Payload并观察响应来完成的。

4.2 案例二：XSS（跨站脚本）漏洞的验证

场景：一个搜索功能，搜索关键词会显示在结果页面上。URL为http://test.com/search?q=keyword。

步骤1：捕获与发送

1. 搜索一个普通词，如“test”，捕获请求：GET /search?q=test HTTP/1.1。
2. 发送至Repeater。

步骤2：探测反射型XSS

1. 修改q参数，尝试一个最简单的探测Payload：q=<script>alert(1)</script>。
2. 点击Send。
3. 分析响应：
   • 查看Raw响应：搜索你的Payload。如果发现<script>alert(1)</script>被原封不动地输出在HTML中（且没有被HTML编码），那么存在反射型XSS的可能性极高。
   • 切换到Render标签：如果Payload被完整输出且浏览器执行了JavaScript，你可能会看到弹窗。但注意：由于Burp Render引擎的安全策略或页面CSP（内容安全策略）限制，可能不会弹窗。此时，Raw响应中未编码的Payload是主要判断依据。
4. 进一步验证：为了确认在真实浏览器中可触发，可以复制Repeater中构造好的完整URL（http://test.com/search?q=<script>alert(1)</script>），粘贴到浏览器地址栏访问。如果弹窗，漏洞确认。

步骤3：探测存储型XSS存储型XSS的请求通常是一个POST请求，比如留言板提交。

1. 捕获提交留言的POST请求，请求体可能为content=Hello World。
2. 发送至Repeater。
3. 修改content参数为XSS Payload，例如content=<img src=x onerror=alert(1)>。
4. 点击Send。服务器通常会返回一个“提交成功”的页面。
5. 关键步骤：此时，你需要手动在浏览器中访问显示留言的页面（例如http://test.com/messages）。观察你刚才提交的留言内容处，是否出现了弹窗，或者检查页面源码看Payload是否被存储并原样输出。
6. 为了在Repeater中模拟，你可以再捕获一次“查看留言”页面的GET请求，发送到另一个Repeater标签页，观察响应中是否包含你的Payload。

注意事项：XSS测试的Payload需要根据上下文灵活变通。如果尖括号被过滤，可以尝试事件处理器（如onmouseover）、伪协议（javascript:alert(1)）或编码绕过。Repeater是尝试这些不同变体的绝佳场所。同时，务必在授权范围内测试，切勿使用破坏性Payload（如alert(document.cookie)在授权测试中可接受，但发送到远程服务器则不可）。

4.3 案例三：文件上传漏洞的绕过测试

场景：一个头像上传功能，只允许上传.jpg, .png图片。

步骤1：捕获上传请求

1. 在浏览器中选择一个正常的图片文件（如test.jpg）上传，Burp Proxy会捕获到一个multipart/form-data格式的POST请求。
2. 发送至Repeater。你会看到请求体内容非常长，包含边界（boundary）、文件字段名、文件名、文件内容等。

步骤2：分析请求结构与修改在Repeater的Raw视图下，你需要找到关键部分：

POST /upload.php HTTP/1.1 ... Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryABC123 ------WebKitFormBoundaryABC123 Content-Disposition: form-data; name="avatar"; filename="test.jpg" Content-Type: image/jpeg (这里是图片的二进制数据，显示为乱码) ------WebKitFormBoundaryABC123--

你需要修改的地方通常有两处：

1. 文件名（filename）：尝试修改为test.php.jpg、test.jpg.php、test.php%00.jpg（空字节截断，需在Hex视图修改）或test.pHp（大小写绕过）。
2. 文件内容：这是难点。一种常见方法是，在请求体末尾，文件二进制数据结束后，边界符之前，直接添加一段PHP代码。但更有效的方法是，使用一个包含WebShell代码的图片文件（图片马），然后只修改文件名。这里我们演示修改文件名。

步骤3：尝试绕过

1. 在Repeater中，找到filename="test.jpg"，将其修改为filename="shell.php.jpg"。
2. 点击Send。
3. 分析响应：查看服务器返回的信息。如果返回“文件类型不允许”，说明后端可能检查了Content-Type头。那么我们找到Content-Type: image/jpeg这一行，确保它仍然是合法的图片类型。如果服务器只保存文件，不重命名，那么上传后的文件可能就是shell.php.jpg。如果服务器存在解析漏洞（如Apache的shell.php.jpg可能被解析为PHP），那么访问这个文件就可能执行代码。
4. 进一步测试：如果filename="shell.php"被直接拒绝，可以尝试双扩展名、大小写、加点、加空格等。例如filename="shell.php."、filename="shell.php "（末尾空格）、filename="shell.pHp"。每次修改后，都在Repeater中发送并观察响应。

实操心得：文件上传漏洞的测试非常依赖对服务器响应信息的解读。除了“成功/失败”外，要仔细看返回的JSON消息或HTML中的提示。有时，服务器会返回上传后的文件路径，这是极其重要的信息。在Repeater中测试，可以快速迭代各种绕过技巧，而无需在浏览器前端频繁选择文件。

4.4 案例四：逻辑漏洞初探 - 越权访问

场景：一个Web应用，用户通过/api/getUserInfo?uid=123来获取自己的个人信息。普通用户A的uid是123，用户B的uid是456。

步骤1：捕获正常请求

1. 以用户A身份登录，访问个人信息页面，Burp捕获到请求：GET /api/getUserInfo?uid=123 HTTP/1.1，请求头中包含A的认证Cookie。
2. 发送至Repeater。

步骤2：测试越权

1. 在Repeater中，我们保持Cookie不变（模拟A的会话持续有效）。
2. 修改请求中的uid参数，从123改为456。
3. 点击Send。
4. 分析响应：
   • 情况一（存在越权）：服务器返回了uid为456的用户B的详细信息（如手机号、邮箱）。这说明后端只依赖了前端传来的uid参数，没有在服务端校验当前会话用户是否有权查看该uid的数据。这就是一个典型的水平越权漏洞。
   • 情况二（权限校验有效）：服务器返回“403 Forbidden”或“无权访问”等提示。这说明后端进行了校验，漏洞不存在。
5. 垂直越权测试：如果用户A是普通用户，你可以尝试访问一些只有管理员才能访问的API端点。例如，捕获一个管理员后台的菜单列表请求/api/admin/menu，用普通用户的Cookie在Repeater中重放，看是否能成功获取数据。

步骤3：利用Repeater进行批量探测对于越权漏洞，有时需要测试大量ID。虽然Intruder更合适，但Repeater也可以进行小范围快速测试。你可以复制多个Repeater标签页，在每个标签页中修改不同的uid值（如457，458，459），然后依次发送，观察响应。这比在Intruder里配置更快，适合快速验证猜想。

注意事项：逻辑漏洞的测试，关键在于理解业务逻辑。Repeater让你能“冻结”某一时刻的请求（包括会话状态），然后只修改你怀疑存在问题的参数，进行对照实验。这是发现“这个参数服务器是否完全信任？”这类问题的利器。测试时务必谨慎，避免修改或破坏他人的真实数据。

5. 高级技巧与场景：应对复杂情况

掌握了基础漏洞的探测后，Repeater还能处理更复杂的场景。

5.1 处理JSON格式的请求

现代API大量使用JSON。在Repeater中测试JSON注入或参数污染，需要一点技巧。

1. 修改Content-Type：确保请求头包含Content-Type: application/json。
2. 在Raw视图编辑：在请求体部分，直接编辑JSON字符串。例如：

   {"username": "admin", "password": "123456"}

3. 测试注入点：假设对username进行测试，可以修改为：

   {"username": "admin' OR '1'='1", "password": "123456"}

   或者测试JSON语法本身：

   {"username": "admin", "password": "123456", "role": "admin"}

   观察服务器是否接受额外的字段并赋予其权限。
4. 注意转义：如果JSON值中包含引号，需要正确转义，如\"。Repeater的Raw编辑需要你手动处理这些。

5.2 测试盲注漏洞

对于布尔盲注或时间盲注，Repeater结合历史记录和Comparer是黄金搭档。

• 布尔盲注：你构造的Payload会让页面返回“存在”或“不存在”两种状态（可能表现为页面内容细微不同、关键词出现与否）。在Repeater中发送两个Payload（如id=1 AND substring(version(),1,1)='5'和id=1 AND substring(version(),1,1)='6'），然后将两次响应发送到Comparer，高亮差异。通过这种“猜解”方式，一位一位地获取数据。
• 时间盲注：Payload包含睡眠函数，如id=1 AND SLEEP(5)。发送后，紧盯响应时间。如果从通常的100ms左右变成了5000ms以上，说明Sleep函数被执行，漏洞存在。在Repeater中，你可以方便地多次发送，确认延迟是稳定的。

5.3 条件竞争漏洞的辅助测试

条件竞争（Race Condition）漏洞测试通常需要高并发工具，但Repeater可以用于初步验证逻辑。例如，一个“兑换优惠券”的接口，可能先查询余额，再扣减。你可以：

1. 捕获一个兑换请求。
2. 在Repeater中打开两个标签页，都放入这个请求。
3. 快速连续点击两个标签页的Send按钮。
4. 观察响应，看是否成功兑换了两次（而余额只够兑换一次）。 虽然这无法模拟真正的并发，但可以快速验证后端逻辑是否存在明显的非原子性操作问题。更严谨的测试需要借助Intruder的涡轮增压（Turbo）模式或外部脚本。

6. 常见问题排查与调试心得

即使对Repeater很熟悉，在实际操作中还是会遇到各种问题。这里分享一些排查思路和心得。

问题1：发送请求后，一直处于“Pending”状态或连接超时。

• 检查目标地址和端口：确认Repeater左上角的目标地址和端口是否正确。特别是如果你从Proxy历史中发送了一个通过域名访问的请求，但目标服务器IP变了，可能需要手动修改。
• 检查网络和代理设置：确保Burp的代理监听器（Proxy -> Options）是运行的，并且浏览器/系统代理设置正确。
• 检查HTTPS证书：如果目标是HTTPS且证书有问题，Burp可能会拦截失败。尝试在浏览器中访问目标，信任Burp的CA证书。
• 服务器端限制：目标可能对频繁请求进行了限制或封禁。可以等待一会儿再试，或在请求头中添加X-Forwarded-For: 127.0.0.1等头尝试绕过（效果有限）。

问题2：修改请求后发送，服务器返回的错误与预期不符（如500错误）。

• 检查请求格式：这是最常见的原因。特别是修改了multipart/form-data或JSON格式的请求体时，很容易破坏格式。
  • 对于multipart/form-data，检查边界（boundary）字符串是否一致，开头结尾的--是否正确。
  • 对于JSON，检查引号是否成对，末尾是否有逗号。
• 检查请求头：特别是Content-Length头。如果你大幅度修改了请求体（尤其是增加了内容），必须手动更新Content-Length的值为新请求体的字节长度，或者更简单的办法是直接删除Content-Length头，Burp会在发送时自动为你计算并添加。
• 检查参数编码：如果参数值包含特殊字符（如&,=,空格），在GET请求的URL中或POST的x-www-form-urlencoded格式中，需要进行URL编码。在Params标签下修改通常会自动处理，在Raw视图下修改则需要手动编码，或者使用右键的编码功能。

问题3：测试漏洞时，服务器响应总是“正常”，无法判断是否存在漏洞。

• 寻找更细微的差异：不要只看页面“看起来”是否正常。使用Comparer对比响应。关注响应长度（Length）的微小变化、响应时间的差异、HTTP状态码（比如从200变成302重定向）、响应头中某个字段的出现或消失。
• 尝试更广泛的Payload：对于SQL注入，不要只尝试单引号。尝试双引号、反引号、括号、\转义符等。尝试注释符（--,#,/* */）。对于XSS，尝试多种标签和事件处理器。
• 考虑盲注：如果应用屏蔽了错误回显，那么基于布尔或时间的盲注可能就是唯一途径。转变测试思路。
• 检查WAF/防护设备：目标可能存在Web应用防火墙（WAF），它拦截了你的恶意Payload并返回一个伪装成“正常”的页面。观察响应中是否有WAF特有的头（如X-Protected-By）或内容。尝试使用大小写混淆、编码、注释分割等技巧绕过WAF规则。

问题4：会话（Session）失效，导致测试失败。

• 理解会话机制：在Repeater中，你发送的请求会携带最初捕获时的Cookie。如果这个会话过期或被服务器主动销毁，后续请求就会失败（跳转到登录页）。
• 解决方案：
  1. 从浏览器获取新Cookie：在浏览器中重新登录，然后在Proxy中捕获一个新的、有效的请求（比如访问首页），将这个新请求的Cookie头复制到Repeater中替换旧的Cookie。
  2. 使用宏（Macro）：对于需要频繁维持会话的测试，可以在Project options -> Sessions中配置会话处理规则和宏，让Burp自动在会话过期时重新登录并更新Cookie。这是一个高级但非常实用的功能。

个人调试心得：我把Repeater当作一个“HTTP对话模拟器”。我的习惯是，永远保持至少两个标签页：一个叫“基线”（Baseline），里面是最初捕获的、能正常工作的原始请求；另一个或多个是“测试”页。每次测试前，先发送一次“基线”请求，确保环境和会话是正常的。然后，在测试页进行修改和发送。如果测试请求出了问题，可以立刻和基线请求的响应进行对比，快速定位是哪里修改导致了问题。这个习惯能节省大量排查环境问题的时间。

最后，记住一点：熟练使用Repeater的标志，不是你点了多少次“Send”，而是你通过它，真正理解了一次HTTP请求与响应交互背后的故事，并从中找到了通往系统内部的那条隐秘路径。它是最朴实无华的工具，却也是渗透测试者手中最锋利的解剖刀。每一次重放，都是一次向未知领域的探索。