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模块协作视图我们可以把一次完整的手动测试想象成一次“狩猎”Proxy代理这是你的“侦察兵”和“陷阱布置者”。所有浏览器流量都经过它让你能捕获到应用产生的每一个请求。这是你获取“测试样本”的主要来源。Repeater中继器/重放器这是你的“实验室”和“手术台”。你把Proxy抓到的可疑请求送到这里进行详细的、反复的解剖和实验。在这里你验证猜想构造Payload观察细微的响应差异。Intruder入侵者这是你的“自动化攻击集群”。当你通过Repeater确认了某个参数存在漏洞比如一个可爆破的登录点并且需要系统性地尝试大量Payload如字典爆破、模糊测试时就轮到Intruder上场了。它接管了重复性的批量测试工作。Scanner扫描器这是你的“自动化侦察机”。它可以对目标进行主动扫描发现一些常见的、模式化的漏洞。但Scanner的结果往往需要人工在Repeater中进行复核和深入验证以排除误报或挖掘更深层的利用链。Decoder解码器Comparer对比器这些是Repeater的“辅助工具”。Decoder帮你快速对数据进行编码如URL、Base64、HTML或解码方便构造Payload。Comparer则能高亮显示两次响应之间的差异对于盲注、条件竞争等需要对比响应细微变化的漏洞测试至关重要。Repeater的核心定位就是“深度分析”和“精准验证”。它不适合做海量请求的爆破那是Intruder的活也不适合做广度的漏洞发现那是Scanner的活。它的强项在于给你一个“慢镜头”和“显微镜”让你能对单个攻击向量进行极致深入的探究。2.2 实战工作流从捕获到验证一个典型的使用Repeater进行漏洞初探的工作流如下信息收集与浏览配置好浏览器和Burp Proxy正常浏览目标Web应用的所有功能。这时Proxy的历史记录里会积累大量请求。筛选与捕获可疑点在Proxy的HTTP history中根据经验筛选可疑请求。例如所有带参数的GET/POST请求特别是搜索、登录、文件上传、个人资料修改。响应中带有明显错误信息的请求如SQL错误、堆栈跟踪。执行了敏感操作如支付、添加管理员的请求。发送至Repeater右键点击选中的请求选择Send to Repeater。这个请求就被复制到了Repeater模块的一个独立标签页中。请求分析与修改在Repeater界面你可以完整地看到请求的原始格式。这时你需要理解请求结构方法是GET还是POSTContent-Type是什么参数是放在URL里Query String还是请求体里Body有没有特殊的请求头如X-Forwarded-For,Authorization定位测试点确定你要修改哪里。通常是最可能由用户输入控制的参数如id、username、filename、json字段等。构造Payload并重放修改参数值填入你的测试Payload。例如对于SQL注入可能是1 AND 11和1 AND 12对于XSS可能是 。然后点击Send按钮。分析响应这是最关键的一步。仔细查看服务器返回的响应。状态码200成功403禁止500服务器错误404未找到状态码的变化能提供第一层线索。响应体页面内容是否变化是否出现了错误信息是否执行了你的Payload如弹窗长度是否显著不同响应时间对于基于时间的盲注响应时间的差异如延迟5秒是判断漏洞存在与否的核心依据。迭代测试根据上一次的响应调整你的Payload再次发送。这个过程可能会重复几十次甚至上百次直到你能够稳定地触发预期的漏洞行为如获取数据、执行命令。漏洞确认与深化在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 提升效率的实战技巧使用多个Repeater标签页面对一个复杂的功能点我习惯同时打开多个Repeater标签页。比如一个标签页测试正常逻辑一个标签页测试SQL注入另一个测试XSS。这样可以避免来回修改同一个请求也能方便地对比不同攻击向量的响应。右键请求选择Send to Repeater时可以选择发送到新标签页或现有标签页。活用历史记录与Comparer当你测试盲注时响应可能就几个字符的差别。肉眼很难分辨。这时不要只盯着看。将你认为“成功”和“失败”的两次请求的响应分别右键选择Send to Comparer(Response)。在Comparer模块中使用Words或Bytes对比模式它能清晰地高亮出差异部分一目了然。集成Decoder进行快速编码在构造Payload时经常需要URL编码、Base64编码等。不必离开Repeater。选中需要编码的文本右键选择Send to Decoder。在Decoder模块处理完后再复制回Repeater。或者更直接的方式是在Repeater的请求编辑区直接右键也有Convert selection的选项可以进行常见的编码解码操作。管理请求头有些测试需要添加或修改特定的请求头。例如测试HTTP方法覆盖时添加X-HTTP-Method-Override: PUT测试JSON注入时确保Content-Type: application/json测试缓存投毒时修改X-Forwarded-Host。在Headers标签下操作非常方便。关注响应时间在测试基于时间的盲注Time-based Blind SQLi或命令注入Command Injection时响应时间Response timer是唯一的判断依据。在发送一个包含SLEEP(5)或ping -c 5 127.0.0.1的Payload后如果响应时间从几十毫秒变成了5秒多那基本可以断定漏洞存在。Burp的响应时间显示是足够精确的。使用“Go”功能进行上下文测试有些漏洞的触发需要完整的页面上下文比如DOM型XSS或者某些依赖前端JavaScript处理的逻辑漏洞。在Repeater中修改请求后点击Go按钮Burp会用内置的浏览器引擎或配置的外部浏览器打开这个请求让你看到在真实浏览器环境下的效果这对于验证客户端漏洞非常有用。4. 实战演练利用Repeater初探四大常见Web漏洞理论说再多不如动手练一遍。下面我们以四个最常见的漏洞类型为例演示如何从捕获请求开始在Repeater中完成漏洞的初步探测和验证。为了模拟真实环境我会假设一些常见的服务器响应场景。4.1 案例一SQL注入漏洞的探测与验证场景在一个用户查询页面URL是http://test.com/user.php?id1页面显示了用户ID为1的信息。步骤1捕获与发送浏览器访问上述URLBurp Proxy会捕获到请求GET /user.php?id1 HTTP/1.1。在Proxy历史中右键该请求Send to Repeater。步骤2基础探测判断注入点类型在Repeater的请求编辑区我们修改id参数的值。测试1数字型注入探测原始请求id1修改为id1 AND 11逻辑永真修改为id1 AND 12逻辑永假观察响应如果“AND 11”返回正常页面与id1相同而“AND 12”返回异常空页面、错误或与id999类似则极可能存在数字型注入。因为1 AND 12等价于1 AND False整个条件为假可能导致查询无结果。测试2字符型注入探测如果参数是字符串比如nameadmin测试方法类似但要考虑引号闭合。修改为nameadmin AND 11闭合原引号并添加永真条件修改为nameadmin AND 12永假条件观察响应同样对比两者差异。此外可以单独测试一个引号nameadmin。如果返回数据库错误如MySQL的You have an error in your SQL syntax这是字符型注入的强信号。步骤3信息获取验证Union联合查询假设通过步骤2确认存在数字型注入且字段数可测通过order by此步骤略。我们尝试联合查询获取数据库版本。构造Payloadid-1 UNION SELECT 1, version(), 3, 4 --id-1确保原查询无结果使得Union查询的结果能显示出来。version()是获取数据库版本的函数MySQL。--是注释符用于注释掉原查询后面的部分避免语法错误。点击Send。分析响应在响应体中搜索“5.7.32”、“10.4.17-MariaDB”之类的版本字符串。如果找到了那么不仅证明了注入存在还证明了可以通过注入点提取信息。你可以在Repeater中继续修改Union查询尝试database()当前数据库名、user()当前用户等。实操心得Union注入的成功与否很大程度上取决于前端页面显示哪个字段。你需要通过反复测试确定version()放在SELECT后的第几个位置时其返回值会显示在页面上。这个过程就是在Repeater中不断调整Payload并观察响应来完成的。4.2 案例二XSS跨站脚本漏洞的验证场景一个搜索功能搜索关键词会显示在结果页面上。URL为http://test.com/search?qkeyword。步骤1捕获与发送搜索一个普通词如“test”捕获请求GET /search?qtest HTTP/1.1。发送至Repeater。步骤2探测反射型XSS修改q参数尝试一个最简单的探测Payloadqscriptalert(1)/script。点击Send。分析响应查看Raw响应搜索你的Payload。如果发现scriptalert(1)/script被原封不动地输出在HTML中且没有被HTML编码那么存在反射型XSS的可能性极高。切换到Render标签如果Payload被完整输出且浏览器执行了JavaScript你可能会看到弹窗。但注意由于Burp Render引擎的安全策略或页面CSP内容安全策略限制可能不会弹窗。此时Raw响应中未编码的Payload是主要判断依据。进一步验证为了确认在真实浏览器中可触发可以复制Repeater中构造好的完整URLhttp://test.com/search?qscriptalert(1)/script粘贴到浏览器地址栏访问。如果弹窗漏洞确认。步骤3探测存储型XSS存储型XSS的请求通常是一个POST请求比如留言板提交。捕获提交留言的POST请求请求体可能为contentHello World。发送至Repeater。修改content参数为XSS Payload例如contentimg srcx onerroralert(1)。点击Send。服务器通常会返回一个“提交成功”的页面。关键步骤此时你需要手动在浏览器中访问显示留言的页面例如http://test.com/messages。观察你刚才提交的留言内容处是否出现了弹窗或者检查页面源码看Payload是否被存储并原样输出。为了在Repeater中模拟你可以再捕获一次“查看留言”页面的GET请求发送到另一个Repeater标签页观察响应中是否包含你的Payload。注意事项XSS测试的Payload需要根据上下文灵活变通。如果尖括号被过滤可以尝试事件处理器如onmouseover、伪协议javascript:alert(1)或编码绕过。Repeater是尝试这些不同变体的绝佳场所。同时务必在授权范围内测试切勿使用破坏性Payload如alert(document.cookie)在授权测试中可接受但发送到远程服务器则不可。4.3 案例三文件上传漏洞的绕过测试场景一个头像上传功能只允许上传.jpg, .png图片。步骤1捕获上传请求在浏览器中选择一个正常的图片文件如test.jpg上传Burp Proxy会捕获到一个multipart/form-data格式的POST请求。发送至Repeater。你会看到请求体内容非常长包含边界boundary、文件字段名、文件名、文件内容等。步骤2分析请求结构与修改在Repeater的Raw视图下你需要找到关键部分POST /upload.php HTTP/1.1 ... Content-Type: multipart/form-data; boundary----WebKitFormBoundaryABC123 ------WebKitFormBoundaryABC123 Content-Disposition: form-data; nameavatar; filenametest.jpg Content-Type: image/jpeg (这里是图片的二进制数据显示为乱码) ------WebKitFormBoundaryABC123--你需要修改的地方通常有两处文件名filename尝试修改为test.php.jpg、test.jpg.php、test.php%00.jpg空字节截断需在Hex视图修改或test.pHp大小写绕过。文件内容这是难点。一种常见方法是在请求体末尾文件二进制数据结束后边界符之前直接添加一段PHP代码。但更有效的方法是使用一个包含WebShell代码的图片文件图片马然后只修改文件名。这里我们演示修改文件名。步骤3尝试绕过在Repeater中找到filenametest.jpg将其修改为filenameshell.php.jpg。点击Send。分析响应查看服务器返回的信息。如果返回“文件类型不允许”说明后端可能检查了Content-Type头。那么我们找到Content-Type: image/jpeg这一行确保它仍然是合法的图片类型。如果服务器只保存文件不重命名那么上传后的文件可能就是shell.php.jpg。如果服务器存在解析漏洞如Apache的shell.php.jpg可能被解析为PHP那么访问这个文件就可能执行代码。进一步测试如果filenameshell.php被直接拒绝可以尝试双扩展名、大小写、加点、加空格等。例如filenameshell.php.、filenameshell.php 末尾空格、filenameshell.pHp。每次修改后都在Repeater中发送并观察响应。实操心得文件上传漏洞的测试非常依赖对服务器响应信息的解读。除了“成功/失败”外要仔细看返回的JSON消息或HTML中的提示。有时服务器会返回上传后的文件路径这是极其重要的信息。在Repeater中测试可以快速迭代各种绕过技巧而无需在浏览器前端频繁选择文件。4.4 案例四逻辑漏洞初探 - 越权访问场景一个Web应用用户通过/api/getUserInfo?uid123来获取自己的个人信息。普通用户A的uid是123用户B的uid是456。步骤1捕获正常请求以用户A身份登录访问个人信息页面Burp捕获到请求GET /api/getUserInfo?uid123 HTTP/1.1请求头中包含A的认证Cookie。发送至Repeater。步骤2测试越权在Repeater中我们保持Cookie不变模拟A的会话持续有效。修改请求中的uid参数从123改为456。点击Send。分析响应情况一存在越权服务器返回了uid为456的用户B的详细信息如手机号、邮箱。这说明后端只依赖了前端传来的uid参数没有在服务端校验当前会话用户是否有权查看该uid的数据。这就是一个典型的水平越权漏洞。情况二权限校验有效服务器返回“403 Forbidden”或“无权访问”等提示。这说明后端进行了校验漏洞不存在。垂直越权测试如果用户A是普通用户你可以尝试访问一些只有管理员才能访问的API端点。例如捕获一个管理员后台的菜单列表请求/api/admin/menu用普通用户的Cookie在Repeater中重放看是否能成功获取数据。步骤3利用Repeater进行批量探测对于越权漏洞有时需要测试大量ID。虽然Intruder更合适但Repeater也可以进行小范围快速测试。你可以复制多个Repeater标签页在每个标签页中修改不同的uid值如457458459然后依次发送观察响应。这比在Intruder里配置更快适合快速验证猜想。注意事项逻辑漏洞的测试关键在于理解业务逻辑。Repeater让你能“冻结”某一时刻的请求包括会话状态然后只修改你怀疑存在问题的参数进行对照实验。这是发现“这个参数服务器是否完全信任”这类问题的利器。测试时务必谨慎避免修改或破坏他人的真实数据。5. 高级技巧与场景应对复杂情况掌握了基础漏洞的探测后Repeater还能处理更复杂的场景。5.1 处理JSON格式的请求现代API大量使用JSON。在Repeater中测试JSON注入或参数污染需要一点技巧。修改Content-Type确保请求头包含Content-Type: application/json。在Raw视图编辑在请求体部分直接编辑JSON字符串。例如{username: admin, password: 123456}测试注入点假设对username进行测试可以修改为{username: admin OR 11, password: 123456}或者测试JSON语法本身{username: admin, password: 123456, role: admin}观察服务器是否接受额外的字段并赋予其权限。注意转义如果JSON值中包含引号需要正确转义如\。Repeater的Raw编辑需要你手动处理这些。5.2 测试盲注漏洞对于布尔盲注或时间盲注Repeater结合历史记录和Comparer是黄金搭档。布尔盲注你构造的Payload会让页面返回“存在”或“不存在”两种状态可能表现为页面内容细微不同、关键词出现与否。在Repeater中发送两个Payload如id1 AND substring(version(),1,1)5和id1 AND substring(version(),1,1)6然后将两次响应发送到Comparer高亮差异。通过这种“猜解”方式一位一位地获取数据。时间盲注Payload包含睡眠函数如id1 AND SLEEP(5)。发送后紧盯响应时间。如果从通常的100ms左右变成了5000ms以上说明Sleep函数被执行漏洞存在。在Repeater中你可以方便地多次发送确认延迟是稳定的。5.3 条件竞争漏洞的辅助测试条件竞争Race Condition漏洞测试通常需要高并发工具但Repeater可以用于初步验证逻辑。例如一个“兑换优惠券”的接口可能先查询余额再扣减。你可以捕获一个兑换请求。在Repeater中打开两个标签页都放入这个请求。快速连续点击两个标签页的Send按钮。观察响应看是否成功兑换了两次而余额只够兑换一次。 虽然这无法模拟真正的并发但可以快速验证后端逻辑是否存在明显的非原子性操作问题。更严谨的测试需要借助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。如果这个会话过期或被服务器主动销毁后续请求就会失败跳转到登录页。解决方案从浏览器获取新Cookie在浏览器中重新登录然后在Proxy中捕获一个新的、有效的请求比如访问首页将这个新请求的Cookie头复制到Repeater中替换旧的Cookie。使用宏Macro对于需要频繁维持会话的测试可以在Project options - Sessions中配置会话处理规则和宏让Burp自动在会话过期时重新登录并更新Cookie。这是一个高级但非常实用的功能。个人调试心得我把Repeater当作一个“HTTP对话模拟器”。我的习惯是永远保持至少两个标签页一个叫“基线”Baseline里面是最初捕获的、能正常工作的原始请求另一个或多个是“测试”页。每次测试前先发送一次“基线”请求确保环境和会话是正常的。然后在测试页进行修改和发送。如果测试请求出了问题可以立刻和基线请求的响应进行对比快速定位是哪里修改导致了问题。这个习惯能节省大量排查环境问题的时间。最后记住一点熟练使用Repeater的标志不是你点了多少次“Send”而是你通过它真正理解了一次HTTP请求与响应交互背后的故事并从中找到了通往系统内部的那条隐秘路径。它是最朴实无华的工具却也是渗透测试者手中最锋利的解剖刀。每一次重放都是一次向未知领域的探索。