在 Web 應(yīng)用中，Cookie 很容易成為安全問題的一部分。從以往的經(jīng)驗來看，對 Cookie 在開發(fā)過程中的使用，很多開發(fā)團隊并沒有形成共識或者一定的規(guī)范，這也使得很多應(yīng)用中的 Cookie 成為潛在的易受攻擊點。在給 Web 應(yīng)用做安全架構(gòu)評審（Security architecture review）的時候，我通常會問設(shè)計人員以下幾個問題：

1. 你的應(yīng)用中，有使用 JavaScript 來操作客戶端 Cookie 嗎？如果有，那么是否必須使用 JavaScript 才能完成此應(yīng)用場景？如果沒有，你的 Cookie 允許 JavaScript 來訪問嗎？


2. 你的網(wǎng)站（可能包含多個 Web 應(yīng)用）中，對于 Cookie 的域（Domain）和路徑（Path）設(shè)置是如何制定策略的？為何這樣劃分？


3. 在有 SSL 的應(yīng)用中，你的 Cookie 是否可以在 HTTP 請求和 HTTPS 請求中通用？

　　在實際的應(yīng)用場景中，Cookie 被用來做得最多的一件事是保持身份認證的服務(wù)端狀態(tài)。這種保持可能是基于會話（Session）的，也有可能是持久性的。不管哪一種，身份認證 Cookie 中包含的服務(wù)端票據(jù)（Ticket）一旦泄露，那么服務(wù)端將很難區(qū)分帶有此票據(jù)的用戶請求是來自于真實的用戶，或者是來自惡意的攻擊者。在實際案例中，造成 Cookie 泄露最多的途徑，是通過跨站腳本（XSS, Cross Site Script）漏洞。攻擊者可以通過一小段 JavaScript 代碼，偷竊到代表用戶身份的重要的 Cookie 標示。由于跨站腳本漏洞是如此的普遍（不要以為簡單的 HTML Encode 就可以避免被跨站，跨站是一門很深的學問，以至于在業(yè)界衍生出一個專用的名詞：跨站師），幾乎每一個網(wǎng)站都無法避免，所以這種方式是實際攻防中被普遍使用的一種手段。

　　避免出現(xiàn)這種問題的首要秘訣就是盡所有的可能，給你的 Cookie 加上 HttpOnly 的標簽。HttpOnly 的具體使用不在本文的討論范圍內(nèi)，否則作者略有騙 InfoQ 稿酬的嫌疑。一個大家所不太熟悉的事實是，HttpOnly 是由微軟在 2000 年 IE6 Sp1 中率先發(fā)明并予以支持的。截止現(xiàn)在，HttpOnly 仍然只是一個廠商標準，但是在過去的十余年中，它得到了眾多瀏覽器的廣泛支持。

　　下表是 OWASP 整理的關(guān)于主流瀏覽器對 HttpOnly 支持情況的一個總結(jié)。從表中可以看出，目前主流的瀏覽器，除了 Android 之外，幾乎都無一例外對這一屬性予以了支持。

　　當然對于中國開發(fā)者來說，需要考慮的問題更加復(fù)雜一些：在這個神奇的地方，有大量的用戶使用的瀏覽器并不在以下的列表中，他們使用的是以下面瀏覽器中的一種或者數(shù)種為內(nèi)核的“精裝版”瀏覽器。這些瀏覽器廠商對于同源策略、HttpOnly Cookie、證書管理等安全規(guī)范的支持情況，有待于進一步調(diào)查。

　　在我看來，一個 Web 應(yīng)用的每一個 Cookie 都應(yīng)該帶上 HttpOnly 的標簽。我沒有看到這個決定可能帶來的負面作用，如果一定要說有的話，那么就是你的應(yīng)用將不能再通過 JavaScript 來讀寫 Cookie 了?？墒沁@真有必要嗎？個人認為，JavaScript 操作 Cookie 是一種不正常的做法；可以用 JavaScript 操作 Cookie 完成的功能，一樣可以用服務(wù)端響應(yīng) Http 頭設(shè)置 Cookie 來完成。相反，設(shè)置所有的 Cookie 為 HttpOnly 帶來的巨大好處則非常明顯：盡管你需要繼續(xù)修復(fù) XSS 漏洞，但是這些漏洞至少暫時不會讓你的用戶遭受大規(guī)模的賬戶損失。

　　關(guān)于 Cookie 的第二個話題是域設(shè)置。

　　瀏覽器在選擇發(fā)送哪些本地 Cookie 到本次請求的服務(wù)端時，有一系列的比較和甄別。這些甄別中最重要的部分是 Domain 和 Path 的吻合。Domain 形如 .abc.com 的 Cookie，會被發(fā)送給所有 abc.com 在 80 端口上的子域請求。但是反之則不行，這就是 Cookie 的域匹配（domain match）原則。

　　在一個大型 Web 站點中，往往有多個應(yīng)用，生存在不同的子域名或路徑下。這些應(yīng)用之間由于共享同一個域名，所以往往可能會彼此有操作對方應(yīng)用 Cookie 的能力。這種情況下，設(shè)計好 Cookie 的 Domain 和 Path 尤為重要。在實際設(shè)計工作中，最重要的一個安全原則就是：最小化授權(quán)。這意味著，你需要將自己的 Cookie 可被訪問到的范圍降至最低。應(yīng)用之間傳遞數(shù)據(jù)和共享信息的解決方案非常多，而通過 Cookie 這種用戶輸入（User input）來共享數(shù)據(jù)，是最不安全的解決方案之一。

　　Cookie 另外一個不太常被使用的屬性是 Secure. 這個屬性啟用時，瀏覽器僅僅會在 HTTPS 請求中向服務(wù)端發(fā)送 Cookie 內(nèi)容。如果你的應(yīng)用中有一處非常敏感的業(yè)務(wù)，比如登錄或者付款，需要使用 HTTPS 來保證內(nèi)容的傳輸安全；而在用戶成功獲得授權(quán)之后，獲得的客戶端身份 Cookie 如果沒有設(shè)置為 Secure，那么很有可能會被非 HTTPS 頁面中拿到，從而造成重要的身份泄露。所以，在你的 Web 站點中，如果使用了 SSL，那么你需要仔細檢查在 SSL 的請求中返回的 Cookie 值，是否指定了 Secure 屬性。

　　除此之外還值得特別指出的是，一些 Web 應(yīng)用除了自己的程序代碼中生成的 Cookie，往往還會從其他途徑生成一些 Cookie。例如由 Web Server 或者應(yīng)用容器自動生成的會話 Cookie，由第三方庫或者框架生成的 Cookie 等等。這些都需要進行有針對性的加固處理。

　　幾乎每個站點都難以離開 Cookie，但 Cookie 的使用因其貌似簡單，而很容易被人輕視。重新審視應(yīng)用中的 Cookie 代碼，幾乎只需要很小的代價就可以獲得巨大的安全收益。

　　參考文章

• http://en.wikipedia.org/wiki/HTTP_cookie


• https://www.owasp.org/index.php/HttpOnly