phpcurl破绽技巧_24 年了终于有人创造 curl 的这个 Bug 了

文章目录 [+]

这是一个关于 cookie、互联网代码和 CVE（通用漏洞表露）的故事。

本文最初发布于 Daniel Stenberg 的个人博客。

phpcurl破绽技巧_24 年了终于有人创造 curl 的这个 Bug 了

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：

%01-%08 / %0b-%0c / %0e-%1f / %7f