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

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

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

一切還得從 1998 年說起。

1998 年 10 月，Stenberg 帶領團隊推出了 curl 4.9 版本。當時，聽過或用過 curl 的人還少得可憐。幾個月之后，curl 官網才宣布新版本的下載量達到了 300。那時，無論從何種意義上講， curl 都還很小眾。

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

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

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

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

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

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

這有兩個很直接的缺點：

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

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

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

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

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

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

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

設置 cookie 的網站把 cookie 發(fā)送到客戶端，對于其發(fā)送的每個 cookie，它都會設置多個屬性。尤其是當需要客戶端發(fā)回 cookie 時，它會設置匹配參數。

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

值得一提的是，1998 年添加到 curl 中的 Cookie 代碼在接受內容方面相當自由，當然，多年來也經過了不少調整和完善，不過它始終與現(xiàn)實世界的網站保持了兼容。對于那部分代碼，Stenberg 修改的主要動力始終是為了使 curl 的 Cookie 處理方式與其他已有的使用 cookie 的代理保持基本一致，并可以互操作。

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

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

例如，curl 會接受下面這樣的 cookie：

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

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

當 curl 將類似那樣的一個 cookie 發(fā)送到 HTTP 服務器時，它的外發(fā)請求中會包含下面這樣一個 header 字段：

cookie: name^a=content^b

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

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

Stenberg 認為，要弄清楚主流瀏覽器是怎么做的還是比較容易的，因為它們的源代碼很容易獲得。事實證明，Chrome 和 Firefox 都已經忽略了包含以下任何字節(jié)的傳入 cookie：

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

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

Bug 修復方面，Stenberg 表示，curl 的修復補丁處理方式非常簡單：拒絕包含一個或多個禁用字節(jié)值的 cookie 字段。Stenberg 認為，這種修改基本是沒有風險的。

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

Stenberg 認為，代碼在發(fā)布時是沒什么問題的，并且在用戶的使用過程中，也基本沒有產生什么問題。它的問題出在，HTTP 服務開始拒絕可能的惡意 HTTP 請求時。如此一來，這段代碼就變成了一種拒絕服務，這或多或少會帶來一些副作用。

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