curl 8.22 修复 Secure Cookie 属性解析绕过问题
curl 项目在 2026 年 9 月 2 日披露并修复了一个低危 Cookie 解析问题。受影响版本在解析 Set-Cookie 响应头时，如果 Secure 属性前紧邻的是水平制表符（ASCII 9）而不是空格，可能会将 Cookie 存入 Cookie jar，却没有保留 Secure 标志。之后，同一主机的明文 HTTP 请求可能携带该 Cookie。
这不是代理服务器本身的漏洞，但它会影响任何通过 curl 或 libcurl 复用 Cookie 的代理工作流，尤其是同时存在 HTTPS、HTTP 回退、出口轮换和长期会话状态的任务。
官方影响范围
官方说明将问题标记为低危，影响 curl 命令行工具和 libcurl。受影响版本为 8.13.0 至 8.21.0，8.22.0 及以上版本已修复。
触发条件需要同时满足：服务端返回包含目标 Cookie 的 Set-Cookie 响应头；Secure 属性前使用水平制表符；客户端启用 Cookie 存储；之后又对同一主机发起明文 HTTP 请求。代理出口是否变化，不会自动清除已经进入 Cookie jar 的状态。
为什么代理与数据采集团队需要关注
代理轮换改变的是网络出口，不等于更换浏览器身份或应用会话。Cookie、认证头、缓存和重定向状态通常保存在客户端。如果同一个 Cookie jar 被多个任务、协议或出口共享，错误解析的 Cookie 可能跨越原本预期的安全边界。
常见风险场景包括：
- HTTPS 请求失败后自动降级到 HTTP；
- 多个代理出口共享同一个 Cookie 文件；
- 抓取器把登录、匿名访问和健康检查放在同一会话；
- 重试逻辑跨协议、跨主机或跨区域继续复用状态；
- 只检查代理 IP 是否变化，却没有检查 Cookie jar 内容。
因此，修复动作不应只停留在“更换代理”。正确重点是升级 curl、隔离会话状态，并验证任何明文路径都不会收到 Secure Cookie。
第一步：盘点 curl 与 Cookie 使用面
先建立一份可审计清单，至少包括：
- curl 命令行版本与 libcurl 运行时版本；
- 使用 Cookie 文件、内存 Cookie jar 或共享会话的任务；
- 允许 HTTP、跟随重定向或进行协议回退的代码路径；
- Cookie jar 是否在租户、账号、代理出口或任务之间复用；
- 生产镜像、无服务器函数、桌面工具和 CI 环境中的版本差异。
不要只检查开发机。容器基础镜像和系统包可能仍然携带旧版 libcurl，即使上层应用看起来已经更新。
第二步：优先升级并限制明文路径
优先升级到 curl 8.22.0 或更高版本。如果短期内无法升级，应采用官方修补方案，并避免在携带 Cookie 的会话中访问明文 HTTP。
同时收紧客户端策略：
- 默认只允许 HTTPS；
- 禁止自动从 HTTPS 降级到 HTTP；
- 对重定向后的协议和主机重新做允许列表检查；
- 将登录态 Cookie jar 与匿名采集、探测和健康检查分离；
- 不要让不同客户或工作负载共用 Cookie 文件。
有关出口绕过与路由验证，可参考站内的代理绕过审计指南。
第三步：执行受控回归测试
在隔离测试环境中建立一个受控响应端点，返回 Secure 属性前带水平制表符的 Set-Cookie。测试目标不是利用第三方站点，而是确认自己的客户端是否正确保存安全属性。
建议流程：
- 使用目标 curl 或 libcurl 构建发起 HTTPS 请求；
- 将 Cookie 写入一次性 Cookie jar；
- 检查 Cookie 是否被记录为仅安全传输；
- 对同一测试主机发起受控 HTTP 请求；
- 确认请求中没有发送该 Cookie；
- 分别在直连、固定代理和轮换代理路径重复测试；
- 删除测试 Cookie jar，不与生产凭据混用。
测试时不要记录真实 Cookie 值。证据应只保留版本、测试编号、协议、出口类型、是否发送 Cookie 和结果时间。
第四步：验证完整会话生命周期
单次 HTTPS 请求通过并不代表整条链路安全。还应覆盖重定向、重试、代理切换、连接复用和任务恢复。
建议构建以下矩阵：
- HTTPS 到 HTTPS，主机不变；
- HTTPS 重定向到不同主机；
- HTTPS 意外指向 HTTP；
- 代理超时后的同协议重试；
- 固定会话切换为轮换出口；
- 任务重启后加载旧 Cookie jar。
每个场景都要验证协议、目标主机、Cookie 标志和出口策略。重试次数与边界可结合代理重试预算指南设置。
第五步：准备可复现的支持证据
如果升级后仍出现异常，不要提交包含敏感 Cookie 的原始日志。先制作最小化证据包：
- curl 和 libcurl 的完整版本；
- 操作系统或容器镜像标识；
- 已脱敏的请求与响应头结构；
- Cookie jar 标志位，而非 Cookie 值；
- 使用的协议和代理类型；
- 可复现步骤、预期结果与实际结果；
- 是否在直连路径中同样发生。
可使用代理支持升级资料包整理证据，避免把无关日志或凭据发送给支持人员。
发布前检查清单
- [ ] curl 或 libcurl 已升级到 8.22.0 或更高版本；
- [ ] 所有运行环境都完成版本盘点；
- [ ] Cookie 会话默认禁止明文 HTTP；
- [ ] 重定向与重试不会绕过协议限制；
- [ ] Cookie jar 按租户、账号和任务隔离；
- [ ] 直连、固定代理、轮换代理均完成回归测试；
- [ ] 日志和工单不包含 Cookie 值、密码或令牌；
- [ ] 失败时默认停止，而不是静默降级。
常见问题
更换代理 IP 能消除这个问题吗？
不能。代理 IP 变化只改变网络出口，Cookie jar 仍由客户端保存。必须修复客户端版本和会话隔离策略。
只访问 HTTPS 是否还有风险？
只允许 HTTPS 会显著降低这个具体问题导致 Cookie 通过明文发送的机会，但仍应升级，因为重定向、配置漂移或隐藏的健康检查可能引入 HTTP 路径。
受影响的是 curl 命令还是 libcurl？
两者都在官方影响范围内。使用 libcurl 的应用需要确认实际加载的运行时库版本，而不是只检查系统中的 curl 命令。
是否应该把 Cookie 内容写入调试日志？
不应该。记录标志、域、路径和测试结果即可，Cookie 值应始终脱敏或省略。
来源与合规说明
内部研究依据：curl 项目，CVE-2026-80255“secure cookie attribute bypass with tab”，发布日期为 2026 年 9 月 2 日。公开页面不包含外部链接；研究地址仅保存在内部运营记录中。
仅在你拥有或获准测试的系统上执行回归测试。遵守目标网站条款、robots 指令、隐私要求、数据保护法规与合理请求频率。不要用代理规避访问控制、身份验证或地域限制。
