在Web應用中，Cookie很容易成為安全問題的一部分。從以往的經驗來看，對Cookie在開發過程中的使用，很多開發團隊並沒有形成共識或者 一定的規范，這也使得很多應用中的Cookie成為潛在的易受攻擊點。在給Web應用做安全架構評審（Security architecture review）的時候，我通常會問設計人員以下幾個問題：
保持某些系統的高可用性，是一些企業的重中之重，如何設計？
海量數據處理，海量視頻分發，架構熱點難點，盡在架構師峰會！
ArchSummit全球架構師峰會報名啟動！
在實際的應用場景中，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、證書管理等安全規范的支持情況，有待於進一步調查。Browser
Version
Prevents Reads
Prevents Writes
Microsoft Internet Explorer
10
Yes
Yes
Microsoft Internet Explorer
9
Yes
Yes
Microsoft Internet Explorer
8
Yes
Yes
Microsoft Internet Explorer
7
Yes
Yes
Microsoft Internet Explorer
6 (SP1)
Yes
No
Microsoft Internet Explorer
6 (fully patched)
Yes
Unknown
Mozilla Firefox
3.0.0.6+
Yes
Yes
Netscape Navigator
9.0b3
Yes
Yes
Opera
9.23
No
No
Opera
9.5
Yes
No
Opera
11
Yes
Unknown
Safari
3
No
No
Safari
5
Yes
Yes
iPhone (Safari)
iOS 4
Yes
Yes
Google's Chrome
Beta (initial public release)
Yes
No
Google's Chrome
12
Yes
Yes
Android
Android 2.3
Unknown
Unknown
在我看來，一個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://www.infoq.com/cn/articles/cookie-security
