作者 | 平川，凌敏
这是一个关于 cookie、互联网代码和 CVE（通用漏洞披露）的故事。
本文最初发布于 Daniel Stenberg 的个人博客。
curl 作者 Daniel Stenberg 近日在个人博客分享了一个存在 23.9 年的 curl 漏洞。curl 是常用的命令行工具，用来请求 Web 服务器，于 1997 年首次发行。
据 Stenberg 透露，这个漏洞是在 curl 发布后的第 201 天引入的，但是直到第 8930 天，漏洞才修复好。一个持续了 23.9 年的漏洞背后有着怎样的故事？
一切还得从 1998 年说起。
curl 4.9 与 cookie
1998 年 10 月，Stenberg 带领团队推出了 curl 4.9 版本。当时，听过或用过 curl 的人还少得可怜。几个月之后，curl 官网才宣布新版本的下载量达到了 300。那时，无论从何种意义上讲， curl 都还很小众。
curl 4.9 作为第一个带有 “cookie 引擎” 的版本，可以接收 HTTP cookie、解析、识别，并在后续的请求中把 cookie 正确地返回。在 curl 中，处理 cookie 的大部分代码都是 Stenberg 编写的。
那会，cookie 还没有明确的规范，仅有的一份描述 cookie 工作原理的规范，是一份由 Netscape 管理的文档 cookie_spec（感兴趣的同学可以戳链接查看文档副本：https://curl.se/rfc/cookie_spec.html）。这份文档并不完善，有不少信息需要通过查看其它客户端才能了解到。
Stenberg 在实现处理 cookie 的代码时，就是参考了这份文档以及当时浏览器的大致处理方式。
此后十年，IETF（互联网工程任务组）一直在努力创建 cookie 规范，但均以失败而告终。这些早期 cookie 规范的创建者可能觉得，他们创建了标准，世界就会情不自禁地遵守它们，但事实并非如此。cookie 的特殊之处在于，有很多不同的作者、代码库和网站实现了它。因此，很难从根本上改变它们的工作方式。
直到 2011 年，cookie RFC 正式发布了，它记录并解释了 cookie 实际的使用方式，这可以说是真正意义上的 cookie 规范。Stenberg 本人也参与了规范的制定过程，并在其中阐述了自己的观点和意见。对于这份规范的内容，虽然 Stenberg 并不完全赞同，但与此前的各种 cookie 规范相比，cookie RFC 的确是一个巨大的进步。
cookie 双重语法带来的挑战
一开始，新的 cookie 规范并没有给 Stenberg 造成困扰，但很快，规范的特殊编写方式让 Stenberg 倍感头疼：它针对服务器如何发送 cookie 提供了一种字段语法，而针对客户端应该接受什么样的 cookie 提供了另一种语法。也就是说，同样的 cookie，需要两种语法。
这有两个很直接的缺点：
- 规范很难阅读。你很容易就停留在其中一种语法上，以为那就是适合自己用例的，但却没有意识到角色描述是错误的。
- 定义如何发送 cookie 的语法其实并不重要，因为如何接收和处理 cookie 都是由客户端决定的。现有的大型 cookie 解析器（浏览器）有一定程度的自由决定自己接受什么，所以没人注意，也没人关心服务器是否严格遵守了规范中的语法。与此同时，cookie 规范也在持续更新。从几年前开始，IETF 就一直在修订和更新 2011 年的 cookie 规范，计划将世界上一些已实际投入使用的 cookie 扩展添加到规范中。这项 cookie 规范更新工作被称为 6265bis。
curl 也同步进行更新，以确保符合 RFC 6265bis 草案版本的规定。
但是，双重语法仍然是 cookie 规范文档中悬而未决的问题。
随着时间的推移，cookie 的发展变得缓慢。在过去的几十年里，HTTP 规范也就更新了有限的几次，但值得一提的是，HTTP 服务器实现已经实施了更严格的解析策略：
如果传入的 HTTP 请求看上去“非法”或格式不正确，那么 HTTP 服务器就会提前拒绝，把它们挡在门外。对于请求中的控制代码尤其如此。如果你试图将一个包含控制代码（这里的控制代码指的是介于 1 到 31 之间的字节值，不包括 9，9 是 TAB）的请求发送到一个相当新的 HTTP 服务器，那么服务器很可能会拒绝，并返回 400 响应代码。从 2016 年 12 月发布的 2.4.25 版本开始，HTTP 服务器 Apache httpd 就默认启用了此行为。最新版本的 Nginx 似乎也是这样做的。
如果是现在设计 cookie，那么肯定会有所不同。
设置 cookie 的网站把 cookie 发送到客户端，对于其发送的每个 cookie，它都会设置多个属性。尤其是当需要客户端发回 cookie 时，它会设置匹配参数。
在 cookie 的这些参数中，其中有一个是 domain，客户端发送 cookie 时要匹配它。服务器www.example.com可以设置 cookie 的有效范围为整个example.com域，这时，客户端在访问second.example.com 时也会发送 cookie。也就是说，服务器可以将 cookie 设置为适用于“兄弟站点”。
值得一提的是，1998 年添加到 curl 中的 Cookie 代码在接受内容方面相当自由，当然，多年来也经过了不少调整和完善，不过它始终与现实世界的网站保持了兼容。对于那部分代码，Stenberg 修改的主要动力始终是为了使 curl 的 Cookie 处理方式与其他已有的使用 cookie 的代理保持基本一致，并可以互操作。
curl 的 Bug 详情与修复方案
2022 年 6 月底，Stenberg 收到了一份报告，报告怀疑 curl 中存在安全问题。正是这份报告促使 curl 发布了 CVE-2022-35252。
事实证明，源于 1998 年的旧 cookie 代码，会接受包含控制代码的 cookie。控制代码可以是名称或内容的一部分，如果用户启用了“cookie 引擎”，那么 curl 就会存储那些 cookie，并在后续的请求中将它们发送回来。
例如，curl 会接受下面这样的 cookie：
Set-cookie: name^a=content^b; domain=.example.com^a 和 ^b 表示控制代码。由于域可以将 cookie 标记为适用于其他主机，、所以发送到域中所有主机的请求都会包含这个 cookie。
当 curl 将类似那样的一个 cookie 发送到 HTTP 服务器时，它的外发请求中会包含下面这样一个 header 字段：
cookie: name^a=content^b对此，Apache httpd 及其他服务器的默认配置都会返回 400。一个脚本或应用程序在收到这样的 cookie 后，如果后续的请求中还继续发送 cookie，就会遭到拒绝。
Stenberg 复盘后发现，cookie 规范 RFC 6265 5.2 节确实说了，客户端应该丢弃包含控制代码的 cookie，但这部分对用户来说理解起来比较难，需要对文档有深入的研究才能发现。此外，规范并没有提及“控制代码”或是字节值范围。
Stenberg 认为，要弄清楚主流浏览器是怎么做的还是比较容易的，因为它们的源代码很容易获得。事实证明，Chrome 和 Firefox 都已经忽略了包含以下任何字节的传入 cookie：
- / - / - / 其中不包含 （TAB）和 / （行结束符）。
Bug 修复方面，Stenberg 表示，curl 的修复补丁处理方式非常简单：拒绝包含一个或多个禁用字节值的 cookie 字段。Stenberg 认为，这种修改基本是没有风险的。
写在最后
推算起来，有漏洞的代码从 curl 4.9 版本开始就一直存在，curl 7.85.0 版本才完成修复。整个历程有 8729 天（23.9 年）。也就是说，这个 Bug 是在项目发布的第 201 天引入的，到第 8930 天才修复。
Stenberg 认为，代码在发布时是没什么问题的，并且在用户的使用过程中，也基本没有产生什么问题。它的问题出在，HTTP 服务开始拒绝可能的恶意 HTTP 请求时。如此一来，这段代码就变成了一种拒绝服务，这或多或少会带来一些副作用。
或许，这个 Bug 诞生于 RFC 6265 发布之时。或许，它诞生于 HTTP 服务器开始拒绝这些请求时。不管怎样，这个 Bug 创造了一个新的项目记录：它是第四个被发现之前存在了 8000 多天的 Bug。
点击底部阅读原文访问 InfoQ 官网，获取更多精彩内容！
今日好文推荐
接手了一座年收入 2000 万美元的代码“屎山”，我到底是该重写还是该跳槽？
从一线研发到公司创始人，基础软件创业者迷雾中与市场赛跑
Azure CTO 呼吁不要使用 C/C 启动新项目，C 之父回应：你们这些高管就爱喜新厌旧
NGINX 局限太多，Cloudflare 最终放弃它并用 Rust 自研了全新替代品
