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

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

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

在有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標(biāo)示。由于跨站腳本漏洞是如此的普遍(不要以為簡單的HTML Encode就可以避免被跨站，跨站是一門很深的學(xué)問，以至于在業(yè)界衍生出一個專用的名詞：跨站師)，幾乎每一個網(wǎng)站都無法避免，所以這種方式是實際攻防中被普遍使用的一種手段。

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

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

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

在我看來，一個Web應(yīng)用的每一個Cookie都應(yīng)該帶上HttpOnly的標(biāo)簽。我沒有看到這個決定可能帶來的負面作用，如果一定要說有的話，那么就是你的應(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代碼，幾乎只需要很小的代價就可以獲得巨大的安全收益。

點評：cookie保存的數(shù)據(jù)信息可以方便用戶瀏覽，可以方便開發(fā)者更加完善網(wǎng)站資源，但凡事都會有兩面，有好的，也會有壞的。

原文地址： http://www.91ri.org/5198.html