# 代理 Cookie jar 如何保留你没打算保留的会话 HTTP 客户端会让 Cookie 看起来无害，因为浏览器早已让我们习惯了它们。自主代理会改变后果。带有 `Set-Cookie` 的响应，可能让下一次请求获得代理从未请求、从未展示的权限，而且即使原始凭据已经更换，代理仍可能保留这份权限。 把 Cookie jar 当作认证存储，而不是传输细节。如果 API 需要 Cookie 会话，就为这个 jar 指定名称、所有者、较短的生命周期和可观察的边界。如果不需要，就关闭它。我见过太多事故调查，开头都是有人坚持说请求没有凭据，但客户端却悄悄在 `Cookie` 请求头中发送了凭据。 ## Set-Cookie 请求头可能变成第二份凭据 服务器会在响应中发送 `Set-Cookie`，拥有 jar 的客户端可能会在之后的 `Cookie` 请求头中发送这个值。如果这个值标识服务器端会话，从实际效果看，它就是一份凭据。它是在认证请求之后到达的，并不意味着它对下一次请求的授权能力更弱。 这会让团队陷入误区，因为他们关注的是自己有意提供的密钥：bearer token、basic-auth 密码或签名请求。他们会检查密钥的来源，以及它是否会到达代理。随后，HTTP 库在没有任何明确应用代码的情况下接受了会话 Cookie。即使原来的 Authorization 请求头已经消失，下一次请求仍可能成功。 真正重要的区别在于凭据注入和会话延续。凭据注入会把一个已知密钥附加到某个请求上。会话延续则允许服务器签发新的密钥，再让客户端在之后重放它。两者都能授权操作，但通常只有前者会出现在工具的调用参数中。 RFC 6265 把这种交换描述为状态管理：用户代理会存储来自 `Set-Cookie` 的 Cookie 信息，并在 `Cookie` 中返回适用的 Cookie。这种说法有意保持宽泛，因为 Web 浏览器需要这种能力。代理客户端不应仅仅因为 HTTP 协议允许保留状态，就继承浏览器保存状态的习惯。 Cookie 还会改变令牌轮换失败的含义。假设代理使用一个 token 调用 API，收到 `sid=...`，之后又失去了对该 token 的访问权限。如果 API 单独接受会话 Cookie，代理仍然有路径进入该账户。轮换修复了已知凭据，却没有终止已经签发的会话。这既是服务器端会话管理问题，也是客户端隔离问题。两边都要处理。 ## 客户端决定是否存在隐藏状态 `Set-Cookie` 本身不会产生任何效果。客户端必须选择保留它。这种选择可能藏在许多地方：可复用的 HTTP 客户端、库内置的 Cookie 管理器、fetch 包装器、测试工具，或重定向实现中。 有些常见客户端只有在你提供 jar 后才会保留 Cookie。另一些客户端则会在代码附加标准 Cookie 处理器时保留 Cookie。这样一来，共享客户端可能意外共享同一个 jar。不要根据 API 文档或某次调用成功这一事实推断行为。检查客户端的创建方式，并运行探针测试。 一个干净的测试应使用你控制的服务器或无害的测试端点。第一次响应设置一个名称清晰的 Cookie，第二个请求报告它收到的请求头。测试需要分别回答两个问题： 1. 客户端收到 `Set-Cookie` 后是否保留了 Cookie？ 2. 客户端是否在之后符合条件的请求中发送了该 Cookie？ 使用 curl 时，明确指定 Cookie 文件可以让状态变得可见： ``` curl -i -c /tmp/agent-cookie-test.txt https://test.example/session/start HTTP/1.1 200 OK Set-Cookie: agent_probe=run-7f3; Path=/; Secure; HttpOnly curl -i -b /tmp/agent-cookie-test.txt https://test.example/session/echo HTTP/1.1 200 OK {"received_cookie":"agent_probe=run-7f3"} ``` 这个文件正是测试的重点。第一条命令不可能创建隐藏会话，除非有东西保留了它的响应。第二条命令也不可能重放会话，除非它拿到了这个文件。如果你的代理工具把这个文件的等价物放在一个没有名称、进程全局共享的位置，就创建了一个审查时无人能够解释的会话边界。 使用代理实际采用的完整运行路径重复探针测试，包括请求包装器和重定向设置。直接测试 curl 只能证明 curl 的行为，不能证明你的工具。记录 jar 是否从空状态开始、存放在哪里，以及什么操作会清除它。 ## 调用之间的复用不同于运行之间的复用 同一个任务中的几次调用可能需要共享会话。在之后的任务中继续使用该会话，则是另一个决定。把这两种生命周期混在一起，小小的便利就会变成持久权限。 评估行为时要检查三个边界。首先，确认单个请求是否根本需要 Cookie。其次，确认同一个代理进程中的相关调用是否需要 Cookie。第三，确认全新的进程、恢复的任务、另一份凭据或另一个人是否应该继承这些 Cookie。每个“是”都需要明确理由。 随进程消失的内存 jar，比项目目录中的文件更容易控制。文件可能在崩溃、重试、工作区复制或任务执行人变更后继续存在。它也可能出现在支持归档或版本控制状态输出中。`HttpOnly` 无法保护写入它的客户端之外的 Cookie 文件，它只限制浏览器脚本访问 Cookie。 即使同一个模型收到后续提示，我也倾向于让每次代理运行使用全新的 jar。模型在对话上的连续性，不是保留 HTTP 权限的理由。如果后续操作确实需要该会话，就让操作人员批准在同一个命名边界下继续运行，而不是让上一次运行悄悄留下可用会话。 并发调用也需要单独决策。共享 jar 可能造成依赖顺序的行为：请求 A 收到 Cookie，请求 B 在片刻后开始，于是 B 获得了一个它从未建立的会话。这会让复现问题变得极其困难。除非 API 要求协调使用一个会话，而且任务明确拥有它，否则应为并发任务提供不同的 jar。 ## Cookie 作用域并不等于人们想象的安全范围 Cookie 属性可以限制发送范围，但不会让会话变得无害。应把它们看作服务器发送给客户端的路由指令，然后再决定客户端是否应该遵守这些指令。 仅主机 Cookie 会返回给设置它的确切主机。带有 `Domain=example.com` 的 Cookie 可能会返回给符合条件的子域，例如 `api.example.com` 和 `admin.example.com`。RFC 6265 还规定，如果 Domain 值与来源主机不匹配，用户代理应拒绝它。但这并不能解决信任宽泛企业域名下所有子域这一常见错误。 `Path=/billing` 会将 Cookie 限制在路径与 Cookie 路径匹配的请求中。如果 Cookie 通过其他路由到达服务器，它并不能阻止另一个获准路径上的服务器接受同一个 Cookie，也不能代替授权检查。在设计讨论中不要把 Path 当作安全边界。它只是客户端发送 Cookie 的规则。 `Secure` 告诉客户端只通过安全传输发送 Cookie。`HttpOnly` 告诉浏览器不要通过脚本 API 暴露 Cookie。这两个属性都是良好实践，但都不能限制 Cookie 的保留、任务共享、重定向或代理使用 Cookie 的能力。`SameSite` 主要控制浏览器的站点上下文。非浏览器代理不应把它当作跨站行为安全的证明。 还有一个容易犯的错误：调试时记录原始请求头。只删除 `Authorization`、却保留 `Cookie` 的脱敏器，并没有完成认证信息脱敏。记录 Cookie 是否存在、Cookie 名称、声明的 Domain 和 Path、过期类型，以及必要时使用不可逆的关联标识符。不要记录 Cookie 值。 ## 重定向会把 Cookie 测试变成目标测试 重定向不只是换了一个 URL。它可能改变下一个请求由哪台服务器接收、是否保留凭据，以及哪一个响应可以设置状态。要把重定向作为独立流程进行测试。 先设置一个在返回重定向后再设置 Cookie 的端点。然后分别测试每个目标：同一主机、获准的子域、相邻子域和无关主机。观察发出的 `Cookie` 和 `Authorization`。不同 HTTP 技术栈的选择可能不同，包装器也可能覆盖默认行为。 一个有用的测试装置会生成类似这样的简短追踪记录： ``` request 1 GET https://api.example.test/start response 1 302 Location: https://api.example.test/next Set-Cookie: probe=A; Path=/; Secure request 2 GET https://api.example.test/next Cookie: probe=A response 2 200 ``` 然后只修改 Location 主机。如果 `api.example.test` 重定向到 `reports.example.test`，仅主机 Cookie 不应跟随。Domain 作用域的 Cookie 可能会跟随。测试应在运行前写明预期结果，因为让你感到意外的追踪记录才是测试重点，不应被当作麻烦掩盖过去。 如果 API 合约不要求跨源重定向，就拒绝它。如果必须跟随重定向，应比较原始来源和新来源，按照明确规则移除请求凭据，并让新的响应建立新的 Cookie 状态。不要使用宽泛的自动重定向策略，再假设 Cookie 作用域会替你解决问题。 ## 会话测试必须跨越凭据和进程 能发现高代价问题的测试，不是“请求一，请求二”。它要跨越你的运行模型声称能够隔离的边界。 构建一个无害的端点，只有在收到指定的凭据标签后才签发 Cookie，并在每次授权请求中返回会话标签。然后执行以下序列： 1. 使用凭据 A 启动运行 A，并收到 `sid=A`。 2. 使用同一个 jar，但不带凭据 A，发起第二次调用。 3. 使用凭据 B 和空 jar 启动运行 B。 4. 不带凭据，并使用运行 A 中任何已持久化的 jar，启动运行 C。 5. 在测试服务器上撤销凭据 A 或使其会话失效，然后重试运行 A 的 jar。 预期输出取决于策略，而不是一个适用于所有情况的统一答案。基于 Cookie 的 API 可能有意允许运行 A 中的第二次调用。运行 B 不应看到 A 的状态。除非你明确批准持久化，否则运行 C 应失败。如果你的威胁模型要求令牌轮换移除现有访问权限，撤销后测试服务器应拒绝旧会话。 把预期写在测试旁边，不要把它藏在开发人员的记忆中。在测试注释中放一个简洁的表格就够了： ``` run A, same jar, no bearer header: allowed only if session continuation is intended run B, fresh jar, credential B: must identify as B run C, persisted jar, no credential: rejected run A after session invalidation: rejected ``` 这会揭示团队经常混淆的区别：撤销引导凭据与撤销已签发会话不是同一项操作。API 负责人必须使会话失效。代理工具负责人必须避免在获准生命周期之外保留会话。任何一方都不能假设另一方已经处理了这件事。 ## 除非 API 需要，否则关闭隐式 Cookie jar 代理 HTTP 操作的合理默认设置是，不存储 Cookie，也不自动添加 `Cookie` 请求头。响应仍可能包含 `Set-Cookie`。如果审计设计允许，可以记录这件事，然后丢弃 Cookie。下一次调用应使用正常的请求凭据。 这项建议不受欢迎，因为许多邻近 Web 的 API 只有在登录端点之后由客户端保留 Cookie 才能工作。人们会使用共享 jar，让演示和集成测试通过。当文档化 API 支持 bearer token 或其他限定在请求范围内的机制时，这是错误的解决方式。你是在保留不可见权限，以弥补本不该选择的集成路径。 如果 API 确实需要 Cookie，就把 jar 设为一种明确的能力。调用方应在运行开始时选择一个命名且为空的 jar，工具应报告响应何时创建或替换 Cookie，并在运行结束时让 jar 消失。不要让某个端点仅仅通过返回一个请求头，就让所有代理进入持久会话。 一份最小策略可以简单到便于审查： ``` cookie mode: disabled by default allowed mode: ephemeral per agent run persistence: prohibited sharing: prohibited between agent processes redirects: same-origin only unless the action definition permits another origin logging: record cookie names and scope, never values ``` 这项策略有意没有规则引擎那么复杂。聪明的 Cookie 策略会不断增加例外，直到没人能说清哪个操作携带了哪些状态。一小组明确选项，才能给审查人员真正的答案。 ## 审计状态变化，而不只是审计请求 只列出 URL 和状态码的审计记录，会漏掉最有用的事件：某个响应改变了之后调用能够执行的操作。应把 Cookie 状态变化作为一等事件记录，同时不要保留会话密钥本身。 对于每次 HTTP 操作，记录都应能回答：请求是否发送了 Cookie，响应是否设置或清除了 Cookie，哪个 jar 收到了 Cookie，该 jar 是否属于本次运行，以及是否发生了重定向？Cookie 名称和属性通常足以完成诊断。只有在你确实拥有保护和过期管理它们的安全设计时，才保存 Cookie 值，而大多数代理工具并不需要这样做。 当代理使用 Sallyport 执行 HTTP 操作时，vault 可以在操作执行期间将配置好的 API 凭据留在代理之外。这种隔离只有在 HTTP 客户端同样谨慎地处理返回的会话状态时才有用，而不是悄悄把它变成另一条凭据路径。 审计记录还需要一个人类可读的运行边界。如果操作人员撤销某次代理运行，他们应当知道这项操作是否只能阻止之后通过配置凭据发起的调用，还是也会清除与该运行关联的会话状态。如果不会清除，就应明确说明，并让后续进程无法访问剩余状态。 我会加入的第一个测试有意保持无聊：一个端点发送 `Set-Cookie`，下一个端点确认它是否到达，然后由新的代理进程重复调用。在加入重试、重定向、浏览器兼容性或持久缓存前，先运行这个测试。如果从追踪记录中看不出明确答案，说明客户端拥有的权限超过了其界面承认的范围。 ## API 作者可以在无需猜测的情况下让代理更安全 API 作者应说明是否需要 Cookie、什么操作会创建 Cookie、预期生命周期是什么，以及客户端如何使 Cookie 失效。当登录可能签发一个生命周期超过获取它所用凭据的会话时，仅仅写一句“登录后使用此端点”是不够的。 尽可能提供限定在请求范围内的替代方案。Bearer 认证、签名请求或作用域狭窄的操作令牌，通常更容易审计客户端行为，因为每个调用都会公开携带自己的权限。这并不意味着这些机制自动安全，但它们避免了隐藏在客户端内存中的额外重放通道。 如果签发会话 Cookie，就要让会话失效机制真正有效，并对它进行测试。只轮换令牌而不使会话失效，会让操作人员产生已经完成工作的错误感觉。如果同时接受 bearer token 和会话 Cookie，就要定义两者不一致时哪一个优先，并在诊断输出中公开这一选择。 除非服务确实依赖浏览器行为，否则不要要求代理构建者模仿浏览器。代理会重复发起无人值守的调用，而且经常跨越不同任务运行。浏览器长期保留的便利状态，不适合成为这种环境的默认设置。 ## 安全默认值是使用没有记住会话的新客户端 Cookie 支持本身没有问题，没有所有者的状态才是问题。一个短期存在、明确选择的 jar，可能是完成多次调用 API 任务的正确方式。一个因为有人复用了 HTTP 客户端而出现的 jar，则是在等待合适的重试、重定向或凭据轮换来暴露问题。 让工具界面和审计记录都清楚显示会话边界，然后用跨运行测试证明它。请求追踪应让审查人员能够指出代理拥有的每条凭据路径，包括服务器试图交还给它的那些路径。