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

1. 你的應用中，有使用 JavaScript 來操作客戶端 Cookie 嗎？如果有，那么是否必須使用 JavaScript 才能完成此應用場景？如果沒有，你的 Cookie 允許 JavaScript 來訪問嗎？
2. 你的網站（可能包含多個 Web 應用）中，對于 Cookie 的域（Domain）和路徑（Path）設置是如何制定策略的？為何這樣劃分？
3. 在有 SSL 的應用中，你的 Cookie 是否可以在 HTTP 請求和 HTTPS 請求中通用？

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

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

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

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

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

　　關于 Cookie 的第二個話題是域設置。

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

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

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

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

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

　　參考文章

• http://en.wikipedia.org/wiki/HTTP_cookie
• https://www.owASP.org/index.php/HttpOnly

it知識庫：Cookie安全漫談，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。