1. 项目概述为什么“重发请求”是渗透测试的核心技能如果你刚开始接触Burp Suite可能会觉得它功能繁杂无从下手。但当你真正上手后会发现“重发请求”这个看似简单的操作其实是贯穿整个Web安全测试流程的“灵魂”。无论是测试一个登录框是否存在弱口令还是挖掘一个复杂的SQL注入漏洞本质上都是在和HTTP请求打交道。而Burp Suite的Repeater模块就是让你能精细操控这些请求、反复“试探”目标服务器的“手术刀”。简单来说Repeater就是一个HTTP请求的“编辑器和重放器”。它允许你将Burp Proxy拦截到的任何一个请求“抓”过来然后像编辑文本一样随意修改其中的任何部分——URL、参数、请求头、Cookie甚至是请求体。修改之后你可以一键重新发送给服务器并立刻看到服务器的响应。这种“修改-发送-观察”的循环是手工测试漏洞、绕过防护、理解应用逻辑的基石。很多新手会困惑这和直接在浏览器里刷新页面、或者用浏览器的开发者工具修改请求再发送有什么区别区别大了。Repeater提供了无状态、可追溯、高效率的测试环境。在浏览器里你的操作会受缓存、Cookie状态、页面跳转的干扰而Repeater里每一次请求都是独立的你可以清晰地对比修改前后服务器响应的差异并且所有历史请求都保留在列表中方便回溯分析。这就像化学实验你需要一个干净的烧杯和精确的滴管而不是在反应锅里胡乱搅拌。2. Repeater界面深度解析从“能用”到“精通”很多教程只会告诉你Repeater界面有几个区域但真正高效使用它需要理解每个区域的设计意图和隐藏功能。下面我们结合实战拆解每一个部分。2.1 核心功能区请求列表与控件当你第一次打开Repeater标签页左侧上方是一个空白的请求列表。每当你从Proxy、Target甚至Scanner等其他模块发送一个请求到Repeater这里就会新增一个条目默认命名为“Repeater 1”、“Repeater 2”等。一个非常重要的技巧是立即重命名它们。右键点击请求标签选择“Rename this request”根据测试目标命名例如“Login_GET”、“Search_SQLi_Test”。当你在复杂测试中打开了十几个Repeater标签时清晰的命名能救命。请求列表下方的控件栏是操作核心Send发送最常用的按钮。点击后当前编辑的请求会被发送到目标服务器。Cancel取消取消一个正在发送中的请求。这在请求超时或你突然想修改时很有用。箭头按钮历史导航这是被严重低估的功能。左右箭头可以让你在当前请求的修改历史中前后切换。比如你修改了一个参数值发送后看到响应不对点击左箭头就能立刻回到修改前的状态而无需手动撤销或重新从Proxy发送。这在进行参数Fuzz模糊测试时极其高效。2.2 视图与布局如何高效地阅读请求与响应Repeater的主体是并排的请求Request和响应Response视图。默认是水平并排但你可以通过右上角的布局按钮切换为上下排列或组合视图。根据你的屏幕和习惯选择宽屏显示器适合水平布局方便对比上下布局则更适合查看长响应体。视图顶部的四个标签决定了内容的显示格式Pretty美化默认选项。它会自动格式化JSON、HTML等数据对参数进行URL解码让内容更易读。对于日常分析90%的时间你应该停留在这个视图。Raw原始显示原始的、未经任何处理的HTTP报文。当你需要精确查看每一个字节或者复制原始请求用于其他工具如curl时使用。Hex十六进制以十六进制字节形式显示。这个功能在分析非文本内容如图片、PDF文件、二进制协议或查找隐藏的特殊字符如空字节、换行符时至关重要。例如某些文件上传漏洞的绕过就需要在文件内容的特定位置插入十六进制字符。Render渲染将HTTP响应体像浏览器一样渲染出来。这对于测试XSS跨站脚本攻击payload是否执行、或者查看修改参数后页面视觉变化非常直观。在“Render”按钮旁边有一个“\n”按钮显示不可打印字符。点亮它后Pretty和Raw视图中会显示回车\r、换行\n、制表符\t等控制字符。这在处理HTTP头注入、响应拆分等漏洞时是必备技能因为攻击载荷往往依赖于这些不可见字符。2.3 Inspector检查器结构化编辑的利器Inspector面板位于界面右侧它把HTTP请求/响应分解成了结构化的组件。对于新手我强烈建议多使用Inspector而不是直接编辑Raw视图。原因有三防错Inspector会自动处理URL编码、JSON格式化等细节避免你因手动输入错误格式而破坏请求。高效添加、删除、修改参数、头信息只需点击和输入无需在Raw文本中寻找正确位置。清晰它以树状或列表形式展示结构让你对请求的组成部分一目了然。Inspector的核心部分包括Request Attributes请求属性直接修改请求方法GET/POST/PUT等、路径和协议版本。Query Parameters查询参数对于URL中的?key1value1key2value2参数在这里可以方便地增删改。特别注意“URL-encode these characters”选项默认是勾选的确保特殊字符被正确编码。在测试注入时有时需要取消勾选来发送原始payload。Body Parameters主体参数对于POST请求的表单数据application/x-www-form-urlencoded或JSON数据在这里编辑。对于JSON它甚至提供语法高亮和格式化。Cookies查看和修改随请求发送的Cookie。测试会话管理漏洞时常用。Headers请求头/响应头管理所有HTTP头。你可以轻松添加自定义头如X-Forwarded-For、User-Agent等用于测试WAF绕过或逻辑漏洞。实操心得当你从Proxy发送一个请求到Repeater后第一件事不是急着改参数而是先用Inspector快速浏览一遍请求的所有组成部分。这能帮你快速理解这个请求的功能、依赖的会话Cookie以及可能存在的参数点为后续测试建立清晰的“地图”。3. 实战演练从基础修改到漏洞挖掘理解了工具我们通过三个由浅入深的场景来看看Repeater在实战中如何发挥作用。3.1 场景一基础请求篡改与信息收集假设我们在测试一个网站发现其/admin目录返回403禁止访问。一个常见的思路是服务器是否只是通过路径来判断是否可能通过请求头来鉴权操作步骤用浏览器访问http://target.site/admin用Burp Proxy拦截这个GET请求。右键Send to Repeater。在Repeater的Inspector面板中找到“Request Headers”部分点击“Add”添加一个新的HTTP头。输入头名称X-Original-URL这是一个常用于负载均衡器或WAF绕过的头。输入头值/根路径。点击“Send”。观察响应状态码和内容是否变化。如果变成了200并返回了管理员后台那就发现了一个安全配置漏洞。不要停。继续尝试其他常见头如X-Forwarded-Host: localhost、X-Forwarded-For: 127.0.0.1或者直接添加一个FlagAuthorised: True就像很多CTF题目做的那样。每次修改后都点击“Send”并对比响应差异。这个过程的本质是基于已知模式的试探。Repeater让你能快速迭代这些试探并把所有请求和响应记录下来方便横向对比。3.2 场景二参数Fuzz测试与逻辑漏洞挖掘现在测试一个商品详情页URL是/product?id123。我们想测试是否存在水平越权查看他人商品或参数处理漏洞。操作步骤拦截对/product?id123的请求发送到Repeater。在Inspector的“Query Parameters”里找到id参数。系统性地修改id值并重发改为124,125... 测试是否可遍历其他用户商品IDOR漏洞。改为-1、0。程序可能未对非正数做处理导致错误信息泄露或逻辑异常。改为123添加单引号。观察是否返回SQL数据库错误500状态码或包含SQL、syntax等关键词的报错初步判断是否存在SQL注入。改为123 AND 11和123 AND 12。如果两者返回页面不同则存在基于布尔的SQL注入。改为123.1、12a3。测试服务端对非整型输入的处理可能触发类型转换错误。每一次修改都仔细阅读响应。不仅看状态码更要看响应体的内容、长度、返回时间。Burp Repeater的响应视图下方会显示响应大小和接收时间响应时间的显著差异有时就是盲注Blind Injection存在的信号。注意事项在进行此类Fuzz时务必注意目标系统的业务逻辑。盲目测试大量非法ID可能会触发风控警报或对测试数据造成污染。最好在授权的测试环境或CTF靶场中进行。3.3 场景三利用Repeater辅助进行SQL注入攻击我们接续上一个场景假设在测试/about/2页面时发现参数id存在SQL注入。我们通过Repeater来完成一次完整的联合查询注入攻击获取数据库中的敏感信息模拟CTF场景。详细操作流程确认注入点发送GET /about/2。服务器返回500错误并在HTML中泄露了错误SQL语句SELECT firstName, lastName, ... FROM people WHERE id 2。这确认了注入点并告诉我们表名(people)和部分列名。判断列数使用ORDER BY子句。在Repeater中将请求修改为/about/2 ORDER BY 5--发送。如果页面正常说明SELECT语句至少有5列。尝试ORDER BY 6如果报错则确定列数为5。这是联合查询的前提。探测回显点构造联合查询让数据库返回我们可控的数据。发送请求/about/0 UNION ALL SELECT 1,2,3,4,5--。这里将id设为0一个不存在的值确保页面只显示UNION查询的结果。观察页面看数字“1”、“2”等出现在页面的哪个位置如标题、正文这些位置就是我们可以回显数据的地方。获取数据库信息假设数字“1”的位置回显在页面标题。我们就可以替换这个位置来查询信息。例如查询当前数据库名/about/0 UNION ALL SELECT database(),2,3,4,5--。查询所有表名/about/0 UNION ALL SELECT group_concat(table_name),2,3,4,5 FROM information_schema.tables WHERE table_schemadatabase()--。提取目标数据已知表名为people我们想知道它有哪些列。发送/about/0 UNION ALL SELECT group_concat(column_name),2,3,4,5 FROM information_schema.columns WHERE table_namepeople--。假设返回列名包含notes。最终获取Flag现在我们查询people表中id为1的用户的notes字段/about/0 UNION ALL SELECT notes,2,3,4,5 FROM people WHERE id1--。在响应中我们就能看到包含Flag的注释内容。在整个过程中Repeater的优势展露无遗你可以耐心地一步步构造payload每步都清晰看到服务器的反馈随时使用历史导航回退并保留所有测试步骤的记录。这比在命令行中用curl反复测试要直观和高效得多。4. 高级技巧与效率提升指南当你熟悉基础操作后下面这些技巧能让你的测试工作流如虎添翼。4.1 与Intruder模块联动Repeater是手工精测而Intruder是自动化爆破。两者常配合使用。在Repeater中验证Payload在发起大规模的Intruder攻击前先在Repeater中手动测试一两个payload确保你的攻击语法是正确的服务器会按预期响应。从Repeater发送到Intruder在Repeater中右键点击请求选择“Send to Intruder”。这个请求会作为Intruder攻击的模板你标记的位置§§会被保留极大节省了配置时间。分析Intruder结果后回到Repeater当Intruder攻击发现了一个有趣的响应如不同的状态码、特殊的响应长度你可以直接右键点击该结果选择“Send to Repeater”对这个特定的请求进行更深入的手工分析。4.2 使用“Match and Replace”规则实现自动化修改这是一个隐藏的宝藏功能。在Proxy的“Options”标签页中找到“Match and Replace”规则。你可以创建规则让Burp自动修改所有经过Proxy的请求或响应。但更妙的是这些规则在Repeater中也生效。应用场景你正在测试一个需要特定User-Agent头才能访问的API。与其在Repeater里每个请求都手动改一次不如创建一条规则类型Request header匹配项User-Agent:.*替换为User-Agent: MySecretScanner/1.0创建后所有发送到Repeater的请求其User-Agent头都会被自动替换。这保证了测试环境的一致性。4.3 利用“Notes”和“Issues”功能记录思路在复杂的测试中一个Repeater请求可能代表一个潜在的漏洞点。右键点击请求列表中的标签选择“Add note”可以为这个请求添加注释比如“此处修改id为负值导致服务器内部错误可能存在整数溢出”。这相当于给你的测试过程添加了书签。更进一步当你确信某个请求模式代表一个漏洞时可以右键选择“Report issue”。Burp会帮你生成一个结构化的漏洞报告草稿包含请求和响应详情。虽然最终报告需要润色但这个功能极大地简化了工作流程。5. 常见问题与排查技巧实录即使对老手使用Repeater时也会遇到一些坑。下面是我总结的常见问题及解决方法。问题现象可能原因排查与解决思路点击“Send”后无响应一直转圈或超时。1. 目标服务器宕机或网络不通。2. Burp的代理设置被改变请求未正确路由。3. 请求中包含了服务器无法处理的非法字符或过大负载导致请求卡住。1. 先用浏览器或ping命令检查目标可达性。2. 检查Burp的Proxy - Options确保代理监听端口正确且已启用。检查浏览器代理设置。3.最实用的一招在Repeater的请求编辑区右键选择“Copy as curl command”。将命令粘贴到终端执行看curl能否收到响应。这能快速定位是Burp的问题还是请求本身的问题。修改请求后发送服务器返回错误如400 Bad Request, 413 Payload Too Large。1. 修改时破坏了HTTP报文格式如删除了必要的空行。2. 修改了请求体长度Content-Length但未同步更新Content-Length头。3. 添加了非法字符或不符合预期的编码。1. 在Raw视图下检查请求格式确保请求行、头、体之间由空行\r\n\r\n正确分隔。2.对于POST请求修改Body后务必关注Content-Length头。Burp通常会自动更新但如果你在Raw视图直接删除大段内容可能需要手动删除或修正该头。一个保险的做法是在Inspector里修改Body Parameters让Burp自动处理。3. 对于JSON数据确保双引号、括号配对。对于URL参数确保特殊字符如,被正确编码Inspector中默认会处理。服务器返回的响应是乱码或Render视图无法显示。1. 服务器返回了压缩内容如gzip但Burp没有自动解压。2. 响应内容是二进制数据如图片而非文本。3. 字符编码不匹配。1. 在响应视图的“Headers”部分查看是否有Content-Encoding: gzip。如果有可以尝试在Proxy的“Options” - “Response Modification”中启用“解压压缩内容”。更直接的方法是在Raw或Hex视图查看原始响应。2. 切换到Hex视图查看二进制内容。如果是图片可以右键选择“Send to Image”如果安装了相关扩展或在其他工具中打开。3. 尝试在响应视图右键选择“Change text encoding”切换不同的编码如UTF-8, GBK尝试。从Proxy发送到Repeater的请求其Host或目标变了。从其他上下文如浏览特定页面时发送的请求可能包含相对路径或特定的Host头。检查Repeater顶部“Target”栏的地址和端口是否正确。如果是从其他域名的请求发送过来的可能需要手动将Target修改为当前测试的目标。同时检查请求行中的URL是否是绝对路径包含http://host如果不是Repeater会结合Target栏的地址发送。测试需要维持会话但Repeater中请求总是返回未登录状态。从Proxy捕获的请求中的Cookie是当时会话的可能已过期。或者修改请求时误删了Cookie头。1. 确保从Proxy发送的是一个已认证的会话请求。2. 在Repeater中不要删除或修改关键的会话Cookie如sessionid,JSESSIONID。3. 如果会话过期需要回到浏览器重新登录捕获一个新的包含有效Cookie的请求再发送到Repeater。可以配合“Match and Replace”规则来自动更新Cookie值。最后再分享一个小技巧当你面对一个非常复杂的请求例如一个多部分表单文件上传带有自定义头和签名在Repeater中直接修改很容易出错。这时可以先将这个请求完整地“Copy to file”右键菜单保存为一个.req文件。然后用文本编辑器仔细修改改好后在Repeater中清空请求编辑区再“Paste from file”贴回来。这为复杂请求的编辑提供了一个更安全的缓冲区。Repeater的熟练度直接决定了你手工测试的深度和效率。它没有太多炫酷的自动化功能但正是这种“手动挡”式的精确控制让你能与目标应用进行最直接的对话理解其每一处细微的反馈从而发现那些自动化工具永远无法捕捉到的逻辑漏洞和边界情况。把它当成你的主力武器花时间去熟悉它的每一个角落你的渗透测试能力必然会迎来质的飞跃。
