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

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


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


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

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

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

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

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

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

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

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

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

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

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

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

　　參考文章

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


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