1. 项目概述：为什么拦截与修改请求是安全测试的基石

在应用安全测试的日常工作中，无论是评估一个崭新的Web应用，还是审计一个复杂的API接口，我们最核心、最频繁的操作是什么？答案很可能是：观察和操纵数据流。而这一切的起点，就是能够精准地“抓住”客户端与服务器之间传递的每一个数据包，并能够随心所欲地“改造”它们。这听起来像是网络工程师或者黑客的专属技能，但实际上，这正是每一位安全工程师、渗透测试人员乃至开发者在进行安全自检时必须掌握的基本功。

Burp Suite，作为这个领域的“瑞士军刀”，其最核心、最强大的功能之一，正是代理拦截与请求修改。它不仅仅是一个工具，更是一个工作台，让你能够置身于数据流的中央，以“上帝视角”审视每一次交互。无论是修改一个Cookie值来尝试越权访问，还是篡改一个参数值来触发SQL注入，亦或是重放一个请求来测试逻辑漏洞，都离不开对请求的拦截与修改。可以说，不会用Burp Suite拦截和修改请求，就等于外科医生不会用手术刀，后续所有的高级测试技巧都无从谈起。

很多人初次接触Burp时，会被它复杂的界面和众多的功能模块吓到。但请相信我，一旦你掌握了拦截与修改请求这个核心操作，你就打开了Burp Suite乃至整个Web安全测试的大门。接下来的内容，我将以一个从业超过十年的测试者视角，带你从零开始，深入每一个细节，不仅告诉你“怎么做”，更会解释“为什么这么做”，以及在实际操作中那些文档里不会写的“坑”和“技巧”。

2. 环境准备与核心代理配置

在开始“拦截”之前，我们必须先搭建好“拦截”的环境。这就像布置一个观察站，需要确保所有经过的“车辆”（网络流量）都能被我们检查到。

2.1 Burp Suite 版本选择与基础配置

首先面临的是版本选择。Burp Suite 主要分为社区版（Community Edition）和专业版（Professional）。对于学习和实战拦截修改请求这一核心功能，社区版完全足够。它包含了Proxy（代理）、Repeater（重放器）、Intruder（入侵者）、Decoder（解码器）等所有拦截修改必需的核心模块。专业版的高级扫描和爬虫功能在初期并非必需。因此，如果你的目标是掌握核心技能，从社区版开始是最经济高效的选择。

安装过程很简单，从官网下载对应系统的安装包即可。启动后，你会看到项目配置向导。这里有一个关键选择：临时项目（Temporary project）还是磁盘项目（Disk project）。我强烈建议，即使是练习，也选择“磁盘项目”。临时项目关闭后所有数据（拦截的历史记录、修改的请求）都会丢失，而磁盘项目会保存你的工作状态和所有数据，方便你下次继续分析。这就像写代码不保存源文件一样危险。

启动后，Burp会默认在本地127.0.0.1:8080开启一个HTTP代理服务。这个端口就是所有流量的入口。你可以通过Proxy->Options选项卡查看和修改代理监听设置。默认配置通常就够用，但有一个细节需要注意：Bind to address选项。如果你需要让同一局域网内的其他设备（如手机、另一台虚拟机）的流量也经过Burp，你需要将其从Loopback only改为All interfaces。不过，在公开或不可信网络环境下，这样做有安全风险，务必谨慎。

2.2 浏览器代理配置与证书安装

配置好Burp的代理服务后，下一步是告诉浏览器：“请把你的所有HTTP/HTTPS请求都发送到127.0.0.1:8080这个地址。”

以Chrome浏览器为例（Firefox等原理类似）：

1. 打开浏览器设置，搜索“代理”。
2. 进入“打开您计算机的代理设置”（这会跳转到系统网络设置）。
3. 在“手动设置代理”中，开启代理，地址填127.0.0.1，端口填8080。
4. 切记，不要勾选“请勿将代理用于本地(Intranet)地址”，否则访问localhost或127.0.0.1的流量不会经过Burp。

注意：很多新手在这里会犯错，他们只配置了浏览器的代理，但系统或一些应用程序可能有自己的代理设置。一个快速的验证方法是，配置完成后，访问http://burp。如果Burp代理工作正常，浏览器会显示Burp Suite的欢迎页面。如果无法访问，请检查防火墙是否放行了8080端口，以及代理配置是否正确。

仅仅配置HTTP代理只能拦截明文的HTTP流量。如今绝大多数网站都使用HTTPS，而HTTPS流量是加密的，直接代理只能看到一团乱码。为了解密HTTPS流量，Burp需要扮演一个“中间人”（MITM）。

这就需要安装Burp的CA（证书颁发机构）证书到你的受信任根证书存储区。

1. 确保代理已开启，浏览器已配置好。
2. 用浏览器访问http://burp，点击右上角的“CA Certificate”按钮，下载证书文件（cacert.der）。
3. 在系统的证书管理工具中（如Windows的“管理用户证书”，macOS的“钥匙串访问”），将这个证书导入到“受信任的根证书颁发机构”中。

完成这一步后，Burp就能对HTTPS流量进行解密和再加密，你就能在Proxy中看到明文的请求和响应了。这是拦截修改HTTPS请求的前提，没有证书，后续所有操作都无法进行。

2.3 拦截开关与模式详解

环境搭好，证书装好，是不是打开浏览器访问任何网站，请求都会自动弹出来让我们修改？并不是。Burp的拦截功能有一个明确的“开关”，并且有多种模式。

在Burp的Proxy->Intercept选项卡中，你会看到一个醒目的按钮：Intercept is on/Intercept is off。这是总开关。只有它为“on”时，请求才会被暂停并显示在拦截面板中。

但这里有一个更精细的控制：Intercept选项卡下的Forward、Drop、Intercept is on按钮下方，有一个Actions菜单，里面可以找到Intercept Client Requests和Intercept Server Responses的规则设置。

• 默认情况：只拦截客户端请求。这是最常用的模式，因为大多数修改都是在请求发出前进行的。
• 拦截服务器响应：这个功能非常有用。比如，你想测试一个修改服务器返回的JSON数据是否能触发客户端XSS，或者想绕过前端的一些校验逻辑，就需要拦截并修改响应。但请注意，开启响应拦截会显著增加测试的复杂性，因为每个请求都会停顿两次（一次请求，一次响应），容易导致会话超时或页面加载异常。我个人的习惯是，除非有明确需要，否则保持响应拦截关闭，通过Proxy->HTTP history查看响应结果即可。

此外，你可以通过Options中的Intercept Client Requests规则来精细化控制拦截哪些请求。例如，你可以通过“取消选中”某些文件类型（如图片、CSS、JS）的拦截，来避免页面加载被大量静态资源请求打断，让测试更流畅。这是一个提升效率的重要技巧。

3. 核心操作：拦截、查看与修改请求实战

当一切准备就绪，那个激动人心的时刻就到了：你的第一个请求被成功拦截，静静地躺在Burp的拦截面板里，等待你的检视和改造。

3.1 请求的捕获与界面解析

打开Intercept is on，然后在浏览器中访问一个目标网址（例如一个登录页面）。浏览器的加载图标会开始旋转并暂停，此时切换回Burp，你应该能在Proxy->Intercept选项卡下看到被捕获的请求。

这个界面是信息密度最高的地方，我们拆开来看：

• 原始请求面板（Raw）：这是最常用的视图，以纯文本形式展示了完整的HTTP请求。包括请求行（方法、URL、协议）、请求头（Headers）和请求体（Body）。对于GET请求，Body通常为空，参数在URL中；对于POST请求，参数通常在Body中，格式可能是application/x-www-form-urlencoded、multipart/form-data或application/json。
• 参数面板（Params）：Burp会自动解析URL和Body中的参数，并在这个面板中以表格形式清晰列出。你可以在这里直接修改参数名和值，比在Raw面板里手动查找修改要方便准确得多，特别是当参数很多时。
• Headers面板：单独列出了所有的请求头信息。你可以轻松地添加、删除或修改任何Header，比如Cookie、User-Agent、X-Forwarded-For等。
• Hex面板：以十六进制形式显示请求，在处理非文本或需要精确修改二进制数据时使用，日常较少用到。

当你分析完一个请求后，你有几个选择：

• Forward：放行这个请求，将其发送给服务器。这是最常用的操作。
• Drop：丢弃这个请求，浏览器端会收到一个错误。可以用来模拟网络中断或过滤掉不需要的请求。
• Action：这是一个功能强大的右键菜单，可以将当前请求发送到其他模块（如Repeater、Intruder、Scanner），或者进行各种编码解码操作。

3.2 请求修改的常见场景与技巧

拦截到请求后，修改才是重头戏。下面通过几个典型场景，展示如何操作并解释背后的原理。

场景一：篡改登录凭证（基础身份验证测试）假设你拦截到一个登录请求，Body是username=user&password=123456。

1. 在Params面板或Raw面板中找到password字段。
2. 将值修改为' or '1'='1（一个经典的SQL注入测试载荷）。
3. 点击Forward。
4. 观察结果：如果登录成功，说明存在SQL注入漏洞；如果返回“密码错误”，则可能不存在或已被过滤。这里的关键不是盲目尝试，而是观察应用程序的响应差异。Burp的HTTP history会记录所有请求和响应，方便你对比。

场景二：越权访问测试（操纵标识参数）假设在查看用户详情页时，URL是https://target.com/user/profile?user_id=1001。

1. 拦截这个GET请求。
2. 将user_id参数的值从1001修改为1000或1002。
3. 放行请求。
4. 观察结果：如果你看到了用户1000或1002的详细信息，这就是一个典型的水平越权漏洞（Insecure Direct Object Reference, IDOR）。原理是应用程序仅通过前端传来的参数识别用户身份，未在服务端做二次权限校验。

场景三：修改请求头（绕过限制或伪装）

• 修改User-Agent：有些网站会对爬虫或特定浏览器的访问进行限制。你可以将其修改为常见的浏览器标识，如Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36。
• 修改X-Forwarded-For：这个头通常用于在代理后面标识原始客户端的IP。你可以将其修改为任意IP，来测试应用是否基于此头进行IP校验或日志记录，但要注意这通常不能真正绕过网络层的IP限制。
• 修改Cookie：这是最关键的头部之一。你可以手动添加一个管理员的会话Cookie，来测试是否存在会话固定或权限校验不严的问题。但Cookie值通常需要从其他途径（如已获得的响应、猜测）获取。

场景四：转换请求方法或内容类型有时，将GET请求改为POST，或者修改Content-Type可能会暴露出不同的处理逻辑或漏洞。

1. 拦截一个GET请求，其参数在URL中。
2. 在Raw面板中，将第一行的GET改为POST。
3. 将URL中的查询参数（?a=1&b=2）剪切，粘贴到请求体中。
4. 在Headers部分添加或修改一行：Content-Type: application/x-www-form-urlencoded。
5. 放行请求。观察服务器是否同时支持GET和POST，处理逻辑是否一致，是否存在参数解析差异导致的漏洞。

3.3 使用Repeater进行精准重放与测试

Intercept面板适合一次性修改和放行，但当我们想对同一个请求进行多次、反复、不同载荷的测试时，频繁拦截和修改就太麻烦了。这时，Repeater模块就该上场了。

操作流程：

1. 在Intercept或HTTP history中，右键点击目标请求，选择Send to Repeater。
2. 切换到Repeater选项卡，你会看到请求已经被完整地复制过来。
3. 在这里，你可以像在Intercept面板中一样随意修改请求的任何部分。
4. 修改完成后，点击右上角的Send按钮，右侧面板会立即显示服务器的响应。
5. 你可以基于响应，再次修改请求，再次发送，形成一个快速的“修改-发送-观察”循环。

Repeater的核心优势：

• 状态保持：每次发送都是独立的，不会影响浏览器会话。你可以大胆测试可能使会话失效的 payload。
• 对比功能：你可以打开多个Repeater标签（Target->Add），将不同修改版本的请求并列发送，直观地对比响应差异。
• 历史记录：每个标签的请求响应历史都会被保存，方便回溯。
• 与其他工具联动：你可以随时将Repeater中的请求再次右键发送到Intruder（用于爆破/模糊测试）或Decoder（用于编码解码）。

实操心得：我习惯将登录请求、关键API接口请求等固定发送到Repeater，作为一个独立的“测试工作台”。在测试逻辑漏洞、竞争条件、或需要精细调整参数时，Repeater是不可或缺的利器。它的存在，让拦截修改从“一次性快照”变成了“可重复实验”。

4. 高级技巧与实战场景深度剖析

掌握了基础操作后，我们来看一些能极大提升测试效率和深度的进阶技巧。这些技巧往往是在真实项目对抗中摸索出来的。

4.1 利用Match and Replace实现自动化修改

想象一个场景：你需要测试一个功能，但每个请求都需要手动添加一个特定的HTTP头，比如X-Custom-Token: test123。手动修改几十上百个请求极其枯燥且容易出错。

Burp的Match and Replace功能就是为此而生。它允许你定义规则，自动对经过代理的请求或响应进行查找和替换。

1. 进入Proxy->Options->Match and Replace。
2. 点击Add，规则类型选择Request header。
3. 在“Match”栏留空（表示匹配所有请求），在“Replace”栏输入X-Custom-Token: test123。
4. 勾选该规则并保存。

现在，所有从你浏览器发出的请求，都会自动带上这个头。你可以用这个功能做很多事：

• 自动修改User-Agent：伪装成移动端或特定浏览器。
• 移除或添加Cookie：实现自动化会话管理。
• 修改Referer：测试Referer校验是否严格。
• 替换请求体中的特定字符串：例如，自动将所有的status=1替换为status=0来测试状态修改漏洞。

注意事项：使用此功能要格外小心，尤其是修改关键参数（如密码、金额）的规则。不恰当的规则可能导致测试数据污染或功能异常。建议为不同的测试目标创建不同的Burp项目配置文件，或者在使用完毕后立即禁用或删除规则。

4.2 针对JSON/XML API的拦截与修改

现代应用大量使用RESTful API，其请求体通常是JSON或XML格式。Burp对此有很好的支持。

对于JSON请求：

1. 当拦截到Content-Type: application/json的请求时，Burp的Params面板可能无法正确解析。
2. 此时，切换到Raw面板直接修改JSON字符串是最直接的方式。但要注意JSON的语法，确保引号、括号配对。
3. 更高效的方法是使用Extension（扩展）。可以安装像 “JSON Beautifier” 或 “Burp’s own “Search” feature in the raw view” 来辅助格式化。或者，使用Action->Paste from file来粘贴一个预先准备好的复杂JSON payload。

一个实战场景：测试JSON注入假设一个更新用户信息的API，请求体是{"name":"Alice","age":25}。 你可以尝试修改为：

• {"name":"Alice","age":"25"}（类型混淆）
• {"name":"Alice","age":25, "admin":true}（添加额外属性）
• {"name":"Alice","age":{"$gt":0}}（如果后端是NoSQL，尝试操作符注入） 修改后发送，观察响应是报错、忽略额外字段，还是真的赋予了admin权限。

对于XML请求： 原理类似，但需要注意XML的闭合标签。你可以尝试XML外部实体（XXE）注入攻击，例如将请求体修改为包含<!DOCTYPE test [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>的payload。Burp的Scanner模块会自动检测此类漏洞，但手动在Repeater中测试能让你更理解原理。

4.3 处理动态参数与反爬机制

在实际测试中，你经常会遇到一些“拦路虎”，比如：

• CSRF Token：每次请求都会变化的令牌，直接重放旧请求会因Token无效而失败。
• 时间戳或随机数：请求中包含timestamp或nonce，用于防止重放攻击。
• 签名（Signature）：请求参数被某种算法（如HMAC-SHA256）签名，任何修改都会导致签名校验失败。

应对策略：

1. 识别与定位：首先，通过对比多次相同操作的请求，找出哪些参数是动态变化的。通常它们具有无意义、长度固定、随请求变化的特点。
2. 利用宏（Macro）自动获取：这是Burp Suite专业版的一个强大功能。你可以在Project options->Sessions中定义宏（Macro），让它自动执行一系列请求（如登录），并从响应中提取新的Token，然后自动应用到后续的请求中。这可以绕过简单的CSRF Token校验。
3. 使用插件（Extension）：对于复杂的签名算法，可能需要编写或使用现成的Burp插件。例如，如果应用使用JWT（JSON Web Token），你可以安装 “JWT Editor” 插件，直接在Burp中解码、修改、重新编码JWT令牌。
4. 对于社区版用户：没有宏功能，可以采取“半自动”方式。在浏览器中正常操作直到获取新Token的页面，拦截那个携带新Token的请求，将其发送到Repeater。然后，在测试其他需要此Token的请求时，手动从Repeater的响应里复制Token值过来。虽然繁琐，但在理解流程上很有帮助。

4.4 拦截移动端App流量

测试对象不仅是网站，还有手机App。其原理相同：让App的流量经过Burp代理。

Android 模拟器/真机配置：

1. 确保电脑和手机在同一局域网。
2. 在Burp的Proxy Listeners中，添加一个绑定到All interfaces的监听器（如0.0.0.0:8080）。
3. 在手机的Wi-Fi设置中，修改当前网络，配置代理为手动，主机名填电脑的局域网IP，端口填8080。
4. 在手机浏览器中访问http://<电脑IP>:8080，下载并安装Burp的CA证书（注意，Android高版本需要在系统设置中手动将下载的证书移至“系统信任的凭据”）。
5. 此时，手机App的HTTP流量应该就能被Burp捕获了。

iOS 设备配置： 过程类似，但安装CA证书更麻烦一些，可能需要通过邮件将证书发到手机，然后在设置->通用->描述文件与设备管理中安装，并需要在关于本机->证书信任设置中完全信任该根证书。

处理HTTPS证书绑定（SSL Pinning）： 许多安全意识强的App会使用SSL Pinning技术，即App内置了服务器的合法证书，只信任该证书，不信任系统CA。这样，Burp的CA证书就无法解密其流量。解决此问题需要反编译App，找到并绕过证书校验逻辑，或者使用像Frida、Objection这样的动态插桩工具来Hook掉证书校验函数。这是一个更高级的话题，但却是移动端测试的必经之路。

5. 问题排查、效率提升与安全实践

即使按照步骤操作，你也一定会遇到各种问题。下面是一些常见问题的排查思路和提升效率的秘诀。

5.1 常见问题与排查清单

5.2 提升拦截测试效率的配置技巧

1. 过滤历史记录（HTTP History Filters）：测试过程中，HTTP history会很快被大量请求填满，包括图片、样式表、脚本等。你可以通过顶部的Filter按钮设置过滤器，例如只显示*.target.com的请求，或者隐藏图片等静态资源。这能让你快速定位到关键的API请求。
2. 设置目标范围（Target Scope）：在Target->Scope中，添加你的目标域名（如*.example.com）。设置后，Burp的很多功能（如爬虫、扫描）会默认限定在此范围内，避免误操作其他网站。同时，在Proxy->Options->Intercept Client Requests中可以设置“And URL Is in target scope”，实现只拦截目标站点的请求，非常清爽。
3. 善用搜索（Search）功能：在Proxy->HTTP history中，你可以使用搜索功能（放大镜图标），在全历史记录中搜索特定的关键词、参数名、Cookie值或正则表达式。这对于寻找敏感信息泄露、定位某个特定功能点的所有请求非常有帮助。
4. 项目级配置与备份：将你的常用配置（如代理监听器、范围、匹配替换规则、证书设置）保存为项目文件（.burp）。针对不同的测试项目加载不同的配置文件，可以保持环境干净，避免规则冲突。

5.3 安全与合规性注意事项

最后，也是最重要的，是安全与合规意识。强大的工具意味着巨大的责任。

• 仅在授权范围内测试：绝对不要使用Burp Suite或其他安全工具对任何你没有书面授权（授权范围需明确包含安全测试）的系统、网站或应用进行测试。未经授权的测试是违法的。
• 使用测试环境：尽量在测试环境（Staging）、预生产环境或专门的漏洞靶场（如DVWA、bWAPP）进行练习。避免对生产环境造成任何影响。
• 谨慎使用Intruder和Scanner：Intruder（爆破模块）和Scanner（主动扫描器）会产生大量请求，可能对目标服务器造成拒绝服务（DoS）影响，或触发告警。在授权测试中，也应与客户确认扫描策略和速率限制。
• 妥善保管项目文件：Burp项目文件中可能包含拦截到的敏感数据，如会话Cookie、身份令牌甚至明文密码。务必加密存储项目文件，并在测试结束后安全地删除。
• 理解业务逻辑：最有效的测试往往建立在对业务逻辑的深刻理解上。盲目篡改参数不如理解“这个参数是做什么用的，修改它可能引发什么后果”。结合业务的功能点（如支付、订单、权限变更）进行测试，往往能发现更严重的安全问题。

拦截与修改请求，是手工安全测试的起点，也是贯穿始终的核心技能。它要求你不仅熟悉工具操作，更要具备对HTTP协议、Web应用架构和业务逻辑的深刻理解。从成功捕获第一个请求，到能自动化处理复杂场景，再到能基于对请求响应的分析推理出潜在漏洞，这条路需要大量的练习和思考。希望这篇基于实战的详细拆解，能成为你Web安全测试之旅上一块坚实的垫脚石。记住，工具是手臂，而头脑才是真正的武器。