鑽石舞台

1998年

1998年，我們推出curl 4.9。在那個年代，少有人聽說過或用過curl。距離curl 網站宣布某個新發布的下載量達到300次還有幾個月的時間要過。當時，curl從頭到尾都是非常小眾的存在。

Curl 4.9是第一個具有 「cookie引擎「的發布。當時curl可接受HTTP cookie 並解析，了解這些cookie 並以正確的方式發回給隨後的請求，就像瀏覽器那樣。我當時負責的是管理cookie部分的curl代碼。

1998年，與cookie如何運作有關的僅有標準是Netscape託管的一個非常簡練的文檔，名字叫cookie_spec。如有興趣閱讀該文檔，可參見文末鏈接。這份文檔實際上記錄的並不是非常好，它省略了大量信息，你不得不通過查看其它客戶端才能搞清楚。

我當時實現的 cookie 代碼就是基於這份文檔，瀏覽器當時似乎就是那樣做的。該文檔似乎適用於無數服務器實現。人們找到了該特性的良好用途。

2000年代

這十年，IETF做出了一些努力創建了cookie標準，但均以失敗告終。這些早期cookie標準的作者很可能認為自己可以創建標準，然後全世界就會魔法般地採用這些標準，但事實並非如此。Cookie 在某種程度上是特殊的：它們由如此多的作者、代碼庫和網站實現，以至於cookie的運作方式被從根本上來講，以「上面命令「的方式改變了，它們的運作方式很困難，甚至可以說是不可能的。

RFC 6265

最終，在2011年，cookie rfc 發布了！這次採用的是與上述方式相反的方法：它主要記錄並澄清了cookie實際上是如何被使用的。

我當時也參與在內，提供了一些看法和觀點。雖然我並非同意該標準中所述的一切，但相比於之前的狀態來說，終於有了一個適當的標準是一個巨大的進步。

雙重語法

當時並未讓我太擔心但至此之後一直困擾我的一件事是該標準的編寫方式：它提供了一個關於服務器應當如何發送cookie的字段語法，並提供了另外一個關於語法客戶端應如何接受cookie的字段語法。

同樣的cookie擁有兩個語法。

這樣做至少存在兩個缺點:

1、標準難以閱讀，我們很容易落入其中一個語法並假設它適用於自己的用例並意外獲得錯誤的角色描述。

2、定義如何發送cookie的語法實際上並不十分相關，因為客戶端才是決定是否應當接受和處理cookie的主體。現有的大量cookie解析器（瀏覽器）在如何接受方面都十分自由，因此沒有人會注意到或者關心服務器是否沒有遵信更加嚴格的標準中的語法。

RFC 6265bis

從幾年前開始，IETF就一直在修訂並更新2011年發布的cookie標準。事情發生了變化，而且一些cookie擴展已得到應用，因此應當被涵蓋在標準中。如果我們執行當前管理cookie的代碼，那麼RFC的舊標準顯然不夠用，而它的更新版本就是6265bis。

Curl 是最新狀態並鈺 RFC6265bis 的初稿合規。

以上提及的雙重語法問題仍然並未解決，不過當我最近分享關於該標準的選擇和想法時遇到了不同尋常的堅決抵制。

我們可以發現，從根本上來講，cookie的運作方式仍然和1998年時是一樣的。當然有一些附加的細微差別和增補，但基本的原則並未改變。而且在cookie標準更新中也將一直如此。

Cookie的其中一個奇特之處在於，它不會像其它web特性那樣在源上運作。

HTTP 請求隧道

雖然隨着時間的流逝，cookie 已發生緩慢改變，但HTTP標準也得到更新並在幾十年來更新數次，但可能更加重要的一點是，HTTP服務器實現執行了更加嚴格的解析策略，如果自由接受，那麼很容易導致災難。嚴重且反覆發生的HTTP請求隧道/走私攻擊已向我們證明了這一點。

為對抗此類攻擊，並降低其它問題的風險。HTTP服務器開始提前拒絕那些看似「非法「或畸形的HTTP請求。在入門前就攔截阻止。具體而言，請求中的控制代碼就是這麼做的。當前，如果嘗試向包含控制代碼的新的HTTP服務器發送請求，那麼很有可能該服務器將拒絕該請求並返迴響應代碼400。這裡所說的」控制代碼「是值在1到31（排除9）之間的字節。

廣為人知的HTTP服務器Apache httpd 自2016年12月發布的2.4.25起，在默認情況下啟用該行為。現代的nginx 版本似乎也會這麼做，不過我並未調查確切的開始日期。

其它主機的cookie

要是今天才開始設計cookie，那麼一定會和現在的樣子不同。

設置cookie的網站將cookie 發送給客戶端。網站會對所發送的cookie設置很多屬性。具體而言，當cookie應當被客戶端再次發回時，它回設置相匹配的參數。

為cookie設置的其中一個參數是需要匹配客戶端發送cookie的域。名為 www.example.com的服務器可為整個 「example.com」域設置cookie，意味着該cookie 隨後由客戶端發送以及當訪問 「second.example.com」時發送。服務器可為「姐妹「網站設置cookie！

最終合二為一

1998年在curl中添加的cookie代碼在所接受的內容方面十分自由。雖然多年來得到調整和優化，但該cookie代碼仍然發揮着作用，而且和真實的網站兼容。

改動cookie代碼的主要動力一直都是確保curl像cookie的其它代理一樣以及能和這些代理在野互操作。

CVE-2022-35252

2022年6月，我們收到了關於curl安全問題的漏洞報告，也就是後來的CVE-2022-35252。

結果證明，1998年的老舊cookie代碼接受包含控制代碼的cookie。這些控制代碼可能是名稱或內容的一部分還好，而如果用戶啟用了 「cookie 引擎「，則curl將存儲這些cookie並將其發送給後續請求。

Curl願意接受的cookie例子如下：

其中 「^a」 和 「^b」 代表的時控制代碼、字節代碼1和2。如上所述，由於該域名可為另外一個主機標記cookie，因此該cookie將被包含在該域所有主機的請求中。

當curl將這種cookie 發送給HTTP服務器時，會在出站請求中包括標頭字段。

Cookie: name^a=content^b

400

默認配置的Apache httpd和其它服務器將返回400。對於接受這些cookie的腳本或應用程序而言，只要cookie還在繼續發送，那麼進一步的請求就會被拒絕，即造成拒絕服務。

標準是怎麼說的？

RFC6265中關於客戶端的部分即5.2節並不容易解釋，而且搞清楚客戶端應當摒棄具有控制cookie的cookie要求對文檔進行深入研究。實際上，標準中並沒有提到「控制代碼」或該字節範圍。我想我可能只是一個標準的糟糕讀者。

瀏覽器

由於熱門瀏覽器的源代碼輕鬆可獲取，因此我們很容易知道它們在幹什麼。當然，結果我們發現 Chrome 和 Firefox 已經忽視了包含任意字節的進站cookie：

該範圍不包括 %09（TAB），%0a/%0d是行尾。

修複方案

Curl的修複方案並不十分了你個人驚訝，只是拒絕包含其中一種或更多被禁的字節值的cookie字段。由於這些字段並未被瀏覽器接受，因此任何合法網站將其用於任何良好目的的風險非常小，因此我認為這種更改幾近零風險。

漏洞年齡

從4.9版本開始，curl中就已經存在這些易受攻擊的代碼，也就是說距離修復該漏洞的版本7.85.0已經過去了8729天（23.9年），也就是說我們在項目的第201天引入該漏洞，並在項目的第8930天將其修復。

當代碼交付時並沒有問題，在大量用戶使用它時也並沒有問題重重。然而，當 HTTP服務器懷疑是惡意的HTTP請求並拒絕時，問題就來了。因此，代碼轉變為拒絕服務差不多只是附帶損害，是一個遺憾的副作用。

可能在RFC6265發布之時，這個漏洞就存在了。也有可能當第一個廣為使用的HTTP服務器開始拒絕這些請求時，這個漏洞就存在了。

項目記錄

一個CVE漏洞在代碼中存在了8729天可以說是一個新紀錄。不過，它仍然在潛伏期超過8000天的CVE漏洞中排名第四。

最後，感謝Stefan Eissing 深挖Apache的歷史詳情，感謝Axel Chong提交了CVE-2022-35252提交的漏洞報告。