mitmproxy server_replay 如何回放已保存的服务端响应并自动刷新过期 Cookie【免费下载链接】mitmproxyAn interactive TLS-capable intercepting HTTP proxy for penetration testers and software developers.项目地址: https://gitcode.com/GitHub_Trending/mi/mitmproxy在自动化测试或接口调试中常见的一种需求是客户端请求继续打向线上环境或任意代理入口但响应全部由之前录制好的会话文件返回避免真实请求到达上游服务器。mitmproxy 的server_replay选项就是为此设计的它会用一组启发式规则把新进来的请求与已保存的响应做匹配并把保存的响应返回给客户端。由于录制时处于未来的 Cookie 过期时间、expires等时间值在回放时可能已经过期mitmproxy 默认会对这些时间字段做刷新保证回放的响应在时间语义上与录制时一致。原理请求如何匹配到已保存的响应根据 Features 文档server_replay选项从保存的 HTTP 会话文件中回放服务端响应使用一组启发式规则把进来的请求与保存的响应匹配默认情况下匹配排除请求头只使用URL 和请求方法做匹配。这使得在请求头自然变化的情况下例如换了 User-Agent也能回放成功匹配规则可以通过server_replay前缀下的一组选项定制包括指定要参与匹配的请求头、要忽略的请求参数等。从实现代码 serverplayback.py 可以看到匹配 key 的构成由以下选项控制选项默认值作用server_replay_ignore_contentfalse忽略请求内容后参与匹配不忽略时内容会进入匹配 keyserver_replay_ignore_params空匹配时忽略的 URL 查询参数server_replay_ignore_payload_params空忽略请求体中application/x-www-form-urlencoded或multipart/form-data里的指定参数server_replay_ignore_hostfalse忽略请求目标主机server_replay_ignore_portfalse忽略请求目标端口server_replay_use_headers空指定哪些请求头必须参与匹配server_replay_reusefalse匹配使用一条保存的响应后不从状态中移除同一响应可被回放多次默认为每条响应只用一次server_replay_extraforward找不到可回放响应时的行为可选forward、kill、204、400、404、500数字值会返回对应的空 HTTP 响应自动刷新date、expires、last-modified 与 Cookie 过期时间Features 文档 的 Response refreshing 一节说明了默认行为直接不改就回放服务端响应常常会导致意外行为。例如录制时还处于未来的 cookie 超时时间在回放时可能已经过去了。默认情况下mitmproxy 会在把响应发给客户端之前先刷新它。date、expires和last-modified头都会被更新为与录制时相同的相对时间偏移——录制时它们在过去回放时也在过去反之亦然。Cookie 的过期时间以相同方式更新。实现位于 http.py 的 Response.refresh以“当前时间 − 录制时的timestamp_start”得到时间差然后对date、expires、last-modified头逐个加上该偏移并对每个set-cookie头调用refresh_set_cookie_header刷新 Cookie 过期属性。这个行为由server_replay_refresh选项控制默认开启true。如果希望原样回放、不刷新任何时间字段将其设为false即可。操作步骤1. 准备一个已保存的会话文件先用 mitmdump 录制一次 HTTP 会话并保存到文件录制阶段浏览器/客户端需指向 mitmproxy 代理若走 TLS 需先配置好 mitmproxy 的证书参见 Certificates 文档mitmdump -w session.mitm录制完成后得到会话文件session.mitm。2. 启动带 server_replay 的代理cmdline.py 中注册了相关命令行参数主路径是用--server-replay短选项-S见 cmdline.py 第 86 行指定保存的会话文件mitmdump --server-replay session.mitm启动后所有进入该代理的 HTTP 请求都会先尝试与session.mitm中的保存响应匹配匹配成功的请求直接返回保存的响应经过默认的时间刷新不会发往上游服务器。如果想同时定制“未匹配请求”的处理方式例如未匹配的请求直接断开而不是转发到上游mitmdump --server-replay session.mitm --server-replay-extra kill或在需要重复回放同一条响应时开启复用mitmdump -S session.mitm --server-replay-reuse3. 在 mitmproxy 交互界面中操作也可以用 mitmproxy 控制台界面mitmproxy动态开始/停止回放。界面按键列表里S对应Start server replay见 mitmproxy_user_interface.cast 录制文件其背后对应的命令在 serverplayback.py 中定义replay.server.file path从文件加载并回放服务端响应replay.server.add flows把当前查看的 flow 的响应追加进回放列表replay.server flows用指定 flow 重新设置回放内容replay.server.stop停止回放并清空回放状态。验证回放是否生效在 mitmproxy 界面或命令行提示符中执行replay.server.count返回当前回放状态中可用的 flow 数量见 serverplayback.py 第 173-175 行确认会话文件已成功加载。通过代理发出一个录制时存在过的请求观察代理返回的是保存的响应而非上游实时响应。检查响应头date、expires、last-modified以及set-cookie中的过期时间应被刷新为相对录制时刻相同的偏移例如录制时expires在请求时间之后 1 小时回放时同样在请求时间之后约 1 小时。如果刷新行为不符合预期确认是否误设了--server-replay-refresh false。发一个录制文件中不存在的请求按server_replay_extra的取值观察行为默认forward时请求被转发到上游并在日志中警告server_playback: returned ... non-replay request仅在设置为数字/kill 时出现对应警告kill时连接被断开设为204/400/404/500时返回对应状态码的空响应。限制与边界匹配是启发式的两个 URL 与请求方法相同但请求内容不同的请求会命中同一条保存响应。若需区分用server_replay_use_headers、server_replay_ignore_params等选项收紧或放宽匹配 key这些选项在运行中变化时recompute_hashes 会基于新规则重建回放索引。默认每条保存响应只被回放一次server_replay_reuse为false同一请求反复发且期望每次拿到保存的响应时需开启--server-replay-reuse。server_replay_kill_extra与server_replay_nopop已弃用分别用server_replay_extrakill和server_replay_reuse替代使用时 mitmproxy 会打印弃用提示。对于部分协议Protocols 文档 明确标注了 “Replay: Client or server replay is not possible yet”server_replay 面向的是可解密的 HTTP 会话不适用于不支持回放的协议。【免费下载链接】mitmproxyAn interactive TLS-capable intercepting HTTP proxy for penetration testers and software developers.项目地址: https://gitcode.com/GitHub_Trending/mi/mitmproxy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考