2.1 代理架构原理

2.1 代理架构原理

本节摘要：Burp 代理是一个位于客户端与服务器之间的检查站：客户端把请求交给它，它先呈现给人、再按人的处置转发。理解监听器、拦截开关、历史记录三件套的分工，是所有后续模块共用的底层模型。本节讲透机理，并用靶场上的第一次改包把机理落成手感。

流量为什么会经过你

上一节末尾链路已通，本节回答链条上的第一个原理问题：一个普通的 HTTP 客户端为什么肯把请求交给 Burp。答案平凡但重要——客户端被显式配置了代理指向。浏览器（或任何遵守代理设置的程序）原本要把请求发往目标服务器，代理设置把"发往哪里"改成了"发给 Burp"，请求头里同时带上真实目标地址。Burp 收到后按人的处置决定转发、暂扣或丢弃。所以代理能看见流量的前提从来不是技术穿透，而是客户端的自愿交付；这也是为什么没走代理配置的流量（比如某些桌面客户端硬编码直连）Burp 天然看不见。

在 Burp 一侧，三个组件分担不同职责。监听器是入口，绑定地址与端口决定了谁能把请求送进来——练习时只绑回环地址是安全底线。拦截开关决定"过路请求要不要停下来给人看"：开着时每个请求停在界面等人处置，关掉时请求照转但全部进历史。历史记录是证据池，它不问 interception 开没开，一律记录经过的请求响应，这就是"拦截是手术刀、历史是监视器"的分工。

图：一个请求的两种命运

案例实录：靶场上的第一次改包

背景。靶场登录表单提交后，页面显示"用户名或密码错误"。表单看起来普通，但你想确认服务端到底依据什么做判断——这决定后续测试往参数 fuzz 走还是往逻辑走。

操作。开拦截，在浏览器提交一次登录，请求停在 Burp 界面。观察消息结构：起始行是表单提交，头部是常规字段，消息体里是账号与密码两个参数。此时不改密码，只把用户名参数追加一个单引号再点转发——目的不是注入，是看服务端对异常输入的反应方式。

POST /login.php HTTP/1.1
Host: lab.local:8088
Content-Type: application/x-www-form-urlencoded
Content-Length: 38

username=admin'&password=whatever
​

结果。响应从"用户名或密码错误"变成了数据库报错回显，页面直接吐出一段 SQL 语法错误信息。

解读。同一个端点、一处字符之差，响应性质完全改变，说明用户名参数进入了服务端 SQL 语句的拼接且错误未做统一处理。注意此刻我们并没有"利用"任何东西——拦截与改写只是把一个假设（拼接存在）变成了一个观察（报错回显）。证据已经够写入测试记录：端点、触发输入、响应差异、截图。

变式。手工改包确认问题后，两种自然延伸：一是把这类"改一个字符看反应"的做法交给 Intruder 批量化，那是第四章的内容；二是把"追加标记、统一观察"沉淀成 match-and-replace 规则，让代理对所有经过请求自动追加测试标记，省去每次手敲——规则配置在代理选项页，生效范围可按请求方向限定。

机理之外的两个实用细节

拦截界面可以直接编辑消息的任何部分，包括把请求方法从 GET 换成 POST、增删头部。编辑时注意两个常被忽略的点：消息体长度变了要同步更新长度头部（多数情况下工具会自动处理，但手工构造时要留意）；有完整性校验的头部被改动可能导致服务端直接拒绝，这类拒绝本身就是一种信息——说明该头部参与了防护。

⚠️ 拦截开着的时候不要离开座位去干别的：所有过路请求都在等你。这是新手最常造成"浏览器假死"假象的原因。

监听器与请求处置的配置细节

监听器是代理的门户，几个配置项值得逐一理解。绑定地址决定谁能连进来：回环地址只有本机能用，练习环境的安全底线；绑定到全部接口是为了手机接入，此时你与同网段设备共享这个入口，评估结束要记得改回。多监听器是常见进阶配置：一个回环监听给浏览器，一个全接口监听给移动端，各自的证书与处置规则独立，互不干扰。请求处置除了拦截的开关，还有按条件拦截——只拦特定路径或包含特定参数的请求，在"只想看登录流程"这类场景下能把噪音降到最低，比全量拦截再逐个放行高效得多。

请求在界面上的呈现也值得花五分钟定制：消息按参数拆解显示还是原始文本显示，二进制内容怎么呈现，响应是否高亮可点击的参数。这些纯偏好设置不改变行为，但会直接影响长时间工作的舒适度——职业工具的重度使用者都会花时间把工作面调成自己的样子，这不是折腾，是效率投资。

替换规则的正确打开方式

前面提过的 match-and-replace 值得单独展开，它是代理层最被低估的自动化。规则四要素：作用方向（请求或响应）、匹配目标（起始行、头部、消息体）、匹配内容、替换内容。三个高价值用法。标记注入：所有出站请求自动追加一个测试标记头，靶场回显里看到标记就知道流量走了你的代理——多环境对照时尤其有用。去噪改写：把响应里大体积的静态资源请求自动改路径丢弃，让历史清爽。行为开关：临时把某个Cookie值统一替换，模拟不同会话状态下的行为差异——比在重放器里逐条改省力。规则按配置库管理（呼应 2.3 节），按项目类型启用不同规则组。

需要克制的时刻同样要说：替换规则是全局静默生效的，规则多了之后"你看到的请求"已经不是"浏览器发出的请求"。排查诡异行为时，第一动作永远是禁用全部规则看原始流量——这条排错纪律能省掉大量的自我怀疑。

高频疑问

问：代理会不会改变请求的行为，比如顺序或时序？
答：会引入少量延迟，单请求场景可忽略。批量与并发行为发生在后续模块，代理本身按序转发。值得注意的是连接复用：某些对连接状态敏感的目标行为可能有差异，靶场练习中基本遇不到，真实评估遇到时把"代理存在"列入变量清单即可。

问：WebSocket 或其他协议的流量怎么处理？
答：代理对 HTTP 系流量全覆盖，WebSocket 消息有专门的历史与拦截视图，处理思路与 HTTP 一致。其余协议不在代理能力范围内，各有专门工具，遇到时如实记录覆盖边界即可。

问：怎么确认"我看到的"就是"目标收到的"？
答：两端对照。代理历史里看发出的内容，靶场侧看收到的内容，中间加一层替换规则或日志即可对齐。对证据要求高的场景（第六章）建议保留两端记录。

与后续章节的接口

本节的改包是手工测试的雏形：提假设、改请求、看差异。第三章把这套动作系统化——先用站点地图把攻击面铺开，再在重放器里反复打磨每一次验证。下一节先解决加密流量的看见问题。

本节要点回顾

• 原理：代理看见流量靠客户端配置交付，不是技术穿透；监听器绑定面决定暴露面。
• 分工：拦截是点状手术刀，历史是全量监视器，练习期应以历史为主、拦截为辅。
• 方法：改包的目的是制造可对比的观察，不是炫技；证据在差异里。
• 自动化铺垫：重复性的改包可沉淀为替换规则或交给批量模块。