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?id1 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或JSONapplication/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?keywordtestpage1 HTTP/1.1。你想测试SQL注入很自然地把keyword的值改成test。这里第一个坑就来了URL编码。当你直接在Repeater的请求行或参数列表里输入test时Burp默认可能不会自动对它进行URL编码。单引号在URL中是一个特殊字符。如果服务器端没有做好处理你的单引号可能无法完整到达后端代码。更稳妥的做法是使用快捷键CtrlU对选中内容进行URL编码或者右键选择“Convert Selection” - “URL” - “URL-encode”。你应该看到keywordtest%27。同理空格会被编码为%20等号是%3D。反过来当你收到一个已经被编码的请求时为了可读性可以用CtrlShiftU进行URL解码。但切记在发送前确保需要编码的特殊字符已被正确编码。一个良好的习惯是在修改完参数后眼睛扫一下请求行看看有没有“裸露”的特殊字符。3.2 使用Params选项卡进行结构化编辑对于复杂的GET请求参数很多在请求行里直接修改容易出错。这时应该切换到“Params”选项卡。这里Burp会把URL中的参数解析成键值对表格你可以清晰地添加、删除、修改每一个参数。这个视图还有一个巨大优势它可以帮你自动管理URL编码。在表格里输入的值Burp会在生成最终请求时自动处理编码问题比你手动在Raw视图里敲更不容易出错。特别是当你需要插入大量特殊字符或Payload时用Params视图是首选。3.3 实战场景自动化参数遍历与状态保持有时你需要快速遍历一个参数的所有可能值。虽然Intruder更适合大规模爆破但Repeater也有轻量级的技巧。比如测试一个ID参数是否存在水平越权/api/user/profile?id1001。你手动改成1002、1003去试很累。你可以这样做在Repeater中发送一次id1001的请求确认正常。然后不要关闭这个标签页。直接修改id值为1002再次发送。关键点来了注意观察和对比响应。除了看数据内容更要关注状态码是否从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参数类似只是数据放在了请求体里。格式是key1value1key2value2。在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请求你需要做两件事将Content-Type头修改为application/json。在请求体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分割成多个部分每个部分有自己的头和信息。手动构造或修改这种请求极具挑战性因为你必须保证Content-Type头里的boundary值和请求体里实际使用的分隔符完全一致。请求体各部分格式完全正确包括换行符。因此对于multipart/form-data类型的请求最佳实践是永远不要尝试在Raw视图里手动从头构建它。正确的方法是使用Proxy拦截一个浏览器正常发出的文件上传请求。将这个完整的请求发送到Repeater。在Repeater中你可以在“Params”选项卡的“Body”部分以类似表格的形式看到文本字段和文件字段。你可以在这里相对安全地修改文本字段的值甚至替换文件字段的文件名和内容内容区域以字节形式显示。如果需要彻底更换文件内容可以先将恶意文件内容用Hex编辑器准备好然后在这里进行替换。5. 混合请求与高级场景实战真实的测试场景往往不是单纯的GET或POST而是它们的混合或变种。5.1 GET参数与POST Body共存有些API设计比较特殊它可能在URL的查询字符串GET参数里传递一些过滤或分页信息同时在请求体POST Body里传递主要的业务数据。例如POST /api/orders?page1size20 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的多个标签页可以完美支持这种测试在第一个标签页完成登录从响应中复制出Token。打开第二个标签页粘贴Token到请求头的Authorization字段发送获取个人资料的请求从响应中复制用户ID。打开第三个标签页构造更新请求同时放入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在编辑和渲染时会消耗大量内存。对于这种情况的建议是在“Repeater options”中可以考虑暂时关闭响应的HTML渲染只查看Raw或Hex视图。如果只是需要修改请求头或少量参数尽量避免在Raw视图里打开整个巨大的请求体。使用Params选项卡进行编辑是更轻量的方式。对于非常大的响应可以直接将其保存到文件右键响应区域选择“Save response to file”然后用外部工具分析。7. 常见问题排查与实战避坑指南即使你对Repeater很熟悉在实际操作中还是会遇到各种奇怪的问题。下面是我总结的一些典型场景和解决方案。7.1 请求发送后无响应或连接失败检查目标主机和端口首先确认请求行中的Host头或绝对URL中的主机地址是否正确。如果是从Proxy拦截的请求通常没问题。但如果你手动修改了可能指向了错误的IP或端口。检查Burp的代理状态确保浏览器或测试工具仍然配置为使用Burp Suite作为代理并且Burp的Proxy监听器是开启的。Repeater本身不依赖代理设置来发送请求它直接建立TCP连接。检查网络和防火墙目标服务器是否可达本地防火墙或目标服务器的防火墙是否拦截了来自你测试机器的流量SSL/TLS问题如果目标是HTTPSRepeater会像浏览器一样处理SSL。但如果目标使用了自签名证书或过时的协议可能会失败。你可以尝试在浏览器中先访问一下目标让Burp的CA证书被信任或者检查Burp的“TLS”设置。7.2 服务器返回400/415错误状态码400 Bad Request这是最常见的客户端错误。立刻检查请求格式HTTP请求行、头、体之间的空行是否完整在Raw视图下检查。头部格式每个请求头是否以CRLF\r\n结尾Burp通常会自动处理。JSON/XML语法如果请求体是JSON或XML语法是否有错误少一个括号、多一个逗号都会导致400。使用在线验证器检查。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 高效工作流建议保持请求历史不要频繁关闭标签页。每个测试用例一个标签页并用标签页名称做好标注双击标签页即可重命名方便回溯。善用“Send to Repeater”从Proxy、Target、Scanner等任何地方都可以右键请求选择“Send to Repeater”这是将流量导入Repeater最快的方式。组合使用工具Repeater适合精细调试。当需要大规模参数爆破时将精心构造好的请求从Repeater右键“Send to Intruder”。当发现一个可疑点需要自动扫描时可以“Send to Scanner”。备份原始请求在对一个请求进行大刀阔斧的修改前可以先在原始标签页上右键选择“Copy URL”或“Copy as curl command”将原始请求保存下来以防改乱后无法恢复。Repeater模块的深度远不止点击“Send”按钮那么简单。它要求测试者对HTTP协议有清晰的理解对目标应用的行为有合理的猜测并且有耐心去观察和比对每一次微调带来的变化。从最基础的GET参数修改到复杂的多部分表单构造再到会话链的跟踪Repeater始终是那个最可靠、最直接的交互界面。掌握它就等于握住了手动安全测试中最锋利的那把解剖刀。所有的自动化工具最终都要回到这里来验证和调试这就是它不可替代的价值所在。
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?id1 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或JSONapplication/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?keywordtestpage1 HTTP/1.1。你想测试SQL注入很自然地把keyword的值改成test。这里第一个坑就来了URL编码。当你直接在Repeater的请求行或参数列表里输入test时Burp默认可能不会自动对它进行URL编码。单引号在URL中是一个特殊字符。如果服务器端没有做好处理你的单引号可能无法完整到达后端代码。更稳妥的做法是使用快捷键CtrlU对选中内容进行URL编码或者右键选择“Convert Selection” - “URL” - “URL-encode”。你应该看到keywordtest%27。同理空格会被编码为%20等号是%3D。反过来当你收到一个已经被编码的请求时为了可读性可以用CtrlShiftU进行URL解码。但切记在发送前确保需要编码的特殊字符已被正确编码。一个良好的习惯是在修改完参数后眼睛扫一下请求行看看有没有“裸露”的特殊字符。3.2 使用Params选项卡进行结构化编辑对于复杂的GET请求参数很多在请求行里直接修改容易出错。这时应该切换到“Params”选项卡。这里Burp会把URL中的参数解析成键值对表格你可以清晰地添加、删除、修改每一个参数。这个视图还有一个巨大优势它可以帮你自动管理URL编码。在表格里输入的值Burp会在生成最终请求时自动处理编码问题比你手动在Raw视图里敲更不容易出错。特别是当你需要插入大量特殊字符或Payload时用Params视图是首选。3.3 实战场景自动化参数遍历与状态保持有时你需要快速遍历一个参数的所有可能值。虽然Intruder更适合大规模爆破但Repeater也有轻量级的技巧。比如测试一个ID参数是否存在水平越权/api/user/profile?id1001。你手动改成1002、1003去试很累。你可以这样做在Repeater中发送一次id1001的请求确认正常。然后不要关闭这个标签页。直接修改id值为1002再次发送。关键点来了注意观察和对比响应。除了看数据内容更要关注状态码是否从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参数类似只是数据放在了请求体里。格式是key1value1key2value2。在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请求你需要做两件事将Content-Type头修改为application/json。在请求体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分割成多个部分每个部分有自己的头和信息。手动构造或修改这种请求极具挑战性因为你必须保证Content-Type头里的boundary值和请求体里实际使用的分隔符完全一致。请求体各部分格式完全正确包括换行符。因此对于multipart/form-data类型的请求最佳实践是永远不要尝试在Raw视图里手动从头构建它。正确的方法是使用Proxy拦截一个浏览器正常发出的文件上传请求。将这个完整的请求发送到Repeater。在Repeater中你可以在“Params”选项卡的“Body”部分以类似表格的形式看到文本字段和文件字段。你可以在这里相对安全地修改文本字段的值甚至替换文件字段的文件名和内容内容区域以字节形式显示。如果需要彻底更换文件内容可以先将恶意文件内容用Hex编辑器准备好然后在这里进行替换。5. 混合请求与高级场景实战真实的测试场景往往不是单纯的GET或POST而是它们的混合或变种。5.1 GET参数与POST Body共存有些API设计比较特殊它可能在URL的查询字符串GET参数里传递一些过滤或分页信息同时在请求体POST Body里传递主要的业务数据。例如POST /api/orders?page1size20 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的多个标签页可以完美支持这种测试在第一个标签页完成登录从响应中复制出Token。打开第二个标签页粘贴Token到请求头的Authorization字段发送获取个人资料的请求从响应中复制用户ID。打开第三个标签页构造更新请求同时放入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在编辑和渲染时会消耗大量内存。对于这种情况的建议是在“Repeater options”中可以考虑暂时关闭响应的HTML渲染只查看Raw或Hex视图。如果只是需要修改请求头或少量参数尽量避免在Raw视图里打开整个巨大的请求体。使用Params选项卡进行编辑是更轻量的方式。对于非常大的响应可以直接将其保存到文件右键响应区域选择“Save response to file”然后用外部工具分析。7. 常见问题排查与实战避坑指南即使你对Repeater很熟悉在实际操作中还是会遇到各种奇怪的问题。下面是我总结的一些典型场景和解决方案。7.1 请求发送后无响应或连接失败检查目标主机和端口首先确认请求行中的Host头或绝对URL中的主机地址是否正确。如果是从Proxy拦截的请求通常没问题。但如果你手动修改了可能指向了错误的IP或端口。检查Burp的代理状态确保浏览器或测试工具仍然配置为使用Burp Suite作为代理并且Burp的Proxy监听器是开启的。Repeater本身不依赖代理设置来发送请求它直接建立TCP连接。检查网络和防火墙目标服务器是否可达本地防火墙或目标服务器的防火墙是否拦截了来自你测试机器的流量SSL/TLS问题如果目标是HTTPSRepeater会像浏览器一样处理SSL。但如果目标使用了自签名证书或过时的协议可能会失败。你可以尝试在浏览器中先访问一下目标让Burp的CA证书被信任或者检查Burp的“TLS”设置。7.2 服务器返回400/415错误状态码400 Bad Request这是最常见的客户端错误。立刻检查请求格式HTTP请求行、头、体之间的空行是否完整在Raw视图下检查。头部格式每个请求头是否以CRLF\r\n结尾Burp通常会自动处理。JSON/XML语法如果请求体是JSON或XML语法是否有错误少一个括号、多一个逗号都会导致400。使用在线验证器检查。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 高效工作流建议保持请求历史不要频繁关闭标签页。每个测试用例一个标签页并用标签页名称做好标注双击标签页即可重命名方便回溯。善用“Send to Repeater”从Proxy、Target、Scanner等任何地方都可以右键请求选择“Send to Repeater”这是将流量导入Repeater最快的方式。组合使用工具Repeater适合精细调试。当需要大规模参数爆破时将精心构造好的请求从Repeater右键“Send to Intruder”。当发现一个可疑点需要自动扫描时可以“Send to Scanner”。备份原始请求在对一个请求进行大刀阔斧的修改前可以先在原始标签页上右键选择“Copy URL”或“Copy as curl command”将原始请求保存下来以防改乱后无法恢复。Repeater模块的深度远不止点击“Send”按钮那么简单。它要求测试者对HTTP协议有清晰的理解对目标应用的行为有合理的猜测并且有耐心去观察和比对每一次微调带来的变化。从最基础的GET参数修改到复杂的多部分表单构造再到会话链的跟踪Repeater始终是那个最可靠、最直接的交互界面。掌握它就等于握住了手动安全测试中最锋利的那把解剖刀。所有的自动化工具最终都要回到这里来验证和调试这就是它不可替代的价值所在。
