本文最初發(fā)布于 Daniel Stenberg 的個(gè)人博客。

curl 作者 Daniel Stenberg 近日在個(gè)人博客分享了一個(gè)存在 23.9 年的 curl 漏洞。curl 是常用的命令行工具，用來(lái)請(qǐng)求 Web 服務(wù)器，于 1997 年首次發(fā)行。

據(jù) Stenberg 透露，這個(gè)漏洞是在 curl 發(fā)布后的第 201 天引入的，但是直到第 8930 天，漏洞才修復(fù)好。一個(gè)持續(xù)了 23.9 年的漏洞背后有著怎樣的故事？

一切還得從 1998 年說(shuō)起。

1998 年 10 月，Stenberg 帶領(lǐng)團(tuán)隊(duì)推出了 curl 4.9 版本。當(dāng)時(shí)，聽(tīng)過(guò)或用過(guò) curl 的人還少得可憐。幾個(gè)月之后，curl 官網(wǎng)才宣布新版本的下載量達(dá)到了 300。那時(shí)，無(wú)論從何種意義上講， curl 都還很小眾。

curl 4.9 作為第一個(gè)帶有 “cookie 引擎” 的版本，可以接收 HTTP cookie、解析、識(shí)別，并在后續(xù)的請(qǐng)求中把 cookie 正確地返回。在 curl 中，處理 cookie 的大部分代碼都是 Stenberg 編寫(xiě)的。

那會(huì)，cookie 還沒(méi)有明確的規(guī)范，僅有的一份描述 cookie 工作原理的規(guī)范，是一份由 Netscape 管理的文檔cookie_spec （感興趣的同學(xué)可以戳鏈接查看文檔副本：https://curl.se/rfc/cookie_spec.html）。這份文檔并不完善，有不少信息需要通過(guò)查看其它客戶(hù)端才能了解到。

Stenberg 在實(shí)現(xiàn)處理 cookie 的代碼時(shí)，就是參考了這份文檔以及當(dāng)時(shí)瀏覽器的大致處理方式。

此后十年，IETF（互聯(lián)網(wǎng)工程任務(wù)組）一直在努力創(chuàng)建 cookie 規(guī)范，但均以失敗而告終。這些早期 cookie 規(guī)范的創(chuàng)建者可能覺(jué)得，他們創(chuàng)建了標(biāo)準(zhǔn)，世界就會(huì)情不自禁地遵守它們，但事實(shí)并非如此。cookie 的特殊之處在于，有很多不同的作者、代碼庫(kù)和網(wǎng)站實(shí)現(xiàn)了它。因此，很難從根本上改變它們的工作方式。

直到 2011 年，cookie RFC 正式發(fā)布了，它記錄并解釋了 cookie 實(shí)際的使用方式，這可以說(shuō)是真正意義上的 cookie 規(guī)范。Stenberg 本人也參與了規(guī)范的制定過(guò)程，并在其中闡述了自己的觀點(diǎn)和意見(jiàn)。對(duì)于這份規(guī)范的內(nèi)容，雖然 Stenberg 并不完全贊同，但與此前的各種 cookie 規(guī)范相比，cookie RFC 的確是一個(gè)巨大的進(jìn)步。

一開(kāi)始，新的 cookie 規(guī)范并沒(méi)有給 Stenberg 造成困擾，但很快，規(guī)范的特殊編寫(xiě)方式讓 Stenberg 倍感頭疼：它針對(duì)服務(wù)器如何發(fā)送 cookie 提供了一種字段語(yǔ)法，而針對(duì)客戶(hù)端應(yīng)該接受什么樣的 cookie 提供了另一種語(yǔ)法。也就是說(shuō)，同樣的 cookie，需要兩種語(yǔ)法。

這有兩個(gè)很直接的缺點(diǎn)：

1. 規(guī)范很難閱讀。你很容易就停留在其中一種語(yǔ)法上，以為那就是適合自己用例的，但卻沒(méi)有意識(shí)到角色描述是錯(cuò)誤的。

2. 定義如何發(fā)送 cookie 的語(yǔ)法其實(shí)并不重要，因?yàn)槿绾谓邮蘸吞幚?cookie 都是由客戶(hù)端決定的?，F(xiàn)有的大型 cookie 解析器（瀏覽器）有一定程度的自由決定自己接受什么，所以沒(méi)人注意，也沒(méi)人關(guān)心服務(wù)器是否嚴(yán)格遵守了規(guī)范中的語(yǔ)法。與此同時(shí)，cookie 規(guī)范也在持續(xù)更新。從幾年前開(kāi)始，IETF 就一直在修訂和更新 2011 年的 cookie 規(guī)范，計(jì)劃將世界上一些已實(shí)際投入使用的 cookie 擴(kuò)展添加到規(guī)范中。這項(xiàng) cookie 規(guī)范更新工作被稱(chēng)為 6265bis。

curl 也同步進(jìn)行更新，以確保符合 RFC 6265bis 草案版本的規(guī)定。

但是，雙重語(yǔ)法仍然是 cookie 規(guī)范文檔中懸而未決的問(wèn)題。

隨著時(shí)間的推移，cookie 的發(fā)展變得緩慢。在過(guò)去的幾十年里，HTTP 規(guī)范也就更新了有限的幾次，但值得一提的是，HTTP 服務(wù)器實(shí)現(xiàn)已經(jīng)實(shí)施了更嚴(yán)格的解析策略：

如果傳入的 HTTP 請(qǐng)求看上去“非法”或格式不正確，那么 HTTP 服務(wù)器就會(huì)提前拒絕，把它們擋在門(mén)外。對(duì)于請(qǐng)求中的控制代碼尤其如此。如果你試圖將一個(gè)包含控制代碼（這里的控制代碼指的是介于 1 到 31 之間的字節(jié)值，不包括 9，9 是 TAB）的請(qǐng)求發(fā)送到一個(gè)相當(dāng)新的 HTTP 服務(wù)器，那么服務(wù)器很可能會(huì)拒絕，并返回 400 響應(yīng)代碼。從 2016 年 12 月發(fā)布的 2.4.25 版本開(kāi)始，HTTP 服務(wù)器 Apache httpd 就默認(rèn)啟用了此行為。最新版本的 Nginx 似乎也是這樣做的。

如果是現(xiàn)在設(shè)計(jì) cookie，那么肯定會(huì)有所不同。

設(shè)置 cookie 的網(wǎng)站把 cookie 發(fā)送到客戶(hù)端，對(duì)于其發(fā)送的每個(gè) cookie，它都會(huì)設(shè)置多個(gè)屬性。尤其是當(dāng)需要客戶(hù)端發(fā)回 cookie 時(shí)，它會(huì)設(shè)置匹配參數(shù)。

在 cookie 的這些參數(shù)中，其中有一個(gè)是 domain，客戶(hù)端發(fā)送 cookie 時(shí)要匹配它。服務(wù)器www.example.com可以設(shè)置 cookie 的有效范圍為整個(gè)example.com域，這時(shí)，客戶(hù)端在訪問(wèn)second.example.com 時(shí)也會(huì)發(fā)送 cookie。也就是說(shuō)，服務(wù)器可以將 cookie 設(shè)置為適用于“兄弟站點(diǎn)”。

值得一提的是，1998 年添加到 curl 中的 Cookie 代碼在接受內(nèi)容方面相當(dāng)自由，當(dāng)然，多年來(lái)也經(jīng)過(guò)了不少調(diào)整和完善，不過(guò)它始終與現(xiàn)實(shí)世界的網(wǎng)站保持了兼容。對(duì)于那部分代碼，Stenberg 修改的主要?jiǎng)恿κ冀K是為了使 curl 的 Cookie 處理方式與其他已有的使用 cookie 的代理保持基本一致，并可以互操作。

2022 年 6 月底，Stenberg 收到了一份報(bào)告，報(bào)告懷疑 curl 中存在安全問(wèn)題。正是這份報(bào)告促使 curl 發(fā)布了 CVE-2022-35252。

事實(shí)證明，源于 1998 年的舊 cookie 代碼，會(huì)接受包含控制代碼的 cookie?？刂拼a可以是名稱(chēng)或內(nèi)容的一部分，如果用戶(hù)啟用了“cookie 引擎”，那么 curl 就會(huì)存儲(chǔ)那些 cookie，并在后續(xù)的請(qǐng)求中將它們發(fā)送回來(lái)。

例如，curl 會(huì)接受下面這樣的 cookie：

Set-cookie: name^a=content^b; domain=.example.com

^a 和 ^b 表示控制代碼。由于域可以將 cookie 標(biāo)記為適用于其他主機(jī)，所以發(fā)送到域中所有主機(jī)的請(qǐng)求都會(huì)包含這個(gè) cookie。

當(dāng) curl 將類(lèi)似那樣的一個(gè) cookie 發(fā)送到 HTTP 服務(wù)器時(shí)，它的外發(fā)請(qǐng)求中會(huì)包含下面這樣一個(gè) header 字段：

cookie: name^a=content^b

對(duì)此，Apache httpd 及其他服務(wù)器的默認(rèn)配置都會(huì)返回 400。一個(gè)腳本或應(yīng)用程序在收到這樣的 cookie 后，如果后續(xù)的請(qǐng)求中還繼續(xù)發(fā)送 cookie，就會(huì)遭到拒絕。

Stenberg 復(fù)盤(pán)后發(fā)現(xiàn)，cookie 規(guī)范 RFC 6265 5.2 節(jié)確實(shí)說(shuō)了，客戶(hù)端應(yīng)該丟棄包含控制代碼的 cookie，但這部分對(duì)用戶(hù)來(lái)說(shuō)理解起來(lái)比較難，需要對(duì)文檔有深入的研究才能發(fā)現(xiàn)。此外，規(guī)范并沒(méi)有提及“控制代碼”或是字節(jié)值范圍。

Stenberg 認(rèn)為，要弄清楚主流瀏覽器是怎么做的還是比較容易的，因?yàn)樗鼈兊脑创a很容易獲得。事實(shí)證明，Chrome 和 Firefox 都已經(jīng)忽略了包含以下任何字節(jié)的傳入 cookie：

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

其中不包含 %09（TAB）和 %0a / %0d（行結(jié)束符）。

Bug 修復(fù)方面，Stenberg 表示，curl 的修復(fù)補(bǔ)丁處理方式非常簡(jiǎn)單：拒絕包含一個(gè)或多個(gè)禁用字節(jié)值的 cookie 字段。Stenberg 認(rèn)為，這種修改基本是沒(méi)有風(fēng)險(xiǎn)的。

推算起來(lái)，有漏洞的代碼從 curl 4.9 版本開(kāi)始就一直存在，curl 7.85.0 版本才完成修復(fù)。整個(gè)歷程有 8729 天（23.9 年）。也就是說(shuō)，這個(gè) Bug 是在項(xiàng)目發(fā)布的第 201 天引入的，到第 8930 天才修復(fù)。

Stenberg 認(rèn)為，代碼在發(fā)布時(shí)是沒(méi)什么問(wèn)題的，并且在用戶(hù)的使用過(guò)程中，也基本沒(méi)有產(chǎn)生什么問(wèn)題。它的問(wèn)題出在，HTTP 服務(wù)開(kāi)始拒絕可能的惡意 HTTP 請(qǐng)求時(shí)。如此一來(lái)，這段代碼就變成了一種拒絕服務(wù)，這或多或少會(huì)帶來(lái)一些副作用。

或許，這個(gè) Bug 誕生于 RFC 6265 發(fā)布之時(shí)?；蛟S，它誕生于 HTTP 服務(wù)器開(kāi)始拒絕這些請(qǐng)求時(shí)。不管怎樣，這個(gè) Bug 創(chuàng)造了一個(gè)新的項(xiàng)目記錄：它是第四個(gè)被發(fā)現(xiàn)之前存在了 8000 多天的 Bug。