Cookie安全漫談（轉）

add by zhj: 我也贊成做者的觀點，JavaScript 操做 Cookie 是一種不正常的作法；能夠用 JavaScript 操做 Cookie 完成的功能，同樣能夠在服務端來完成。

js操做cookie會帶來的風險，好比xss，用戶篡改cookie等。在django的csrf防護機制中，模板中的表單，若是是post請求，都要加上{%csrf_token%}標籤，

這其實就是在服務端從cookie中取出csrftoken，而後給表單增長一個隱藏input，name="crsrmiddlewaretoken" value="{{ csrf_token }}"，這個

變量csrf_token=request.COOKIES['csrftoken']。另外，在模板的js代碼中，也支持渲染時傳入的變量，因此django的csrf防護機制中，當發送ajax時，要

加x-csrftoken這個header，能夠在渲染模板時傳入request.COOKIES['csrftoken']給x-csrftoken，從而就不用在前端js獲取cookie去賦值了。

正如做者所說，js在前端操做cookie能完成的事，經過request.COOKIES均可以在服務端完成。因此設置cookie時建議使用httponly=true

 

須要注意兩點：

1. views.py中返回的函數中的值要用 json.dumps()處理

2. 在網頁上要加一個 safe 過濾器。

views.py

# -*- coding: utf-8 -*-
 
from __future__ import unicode_literals
 
import json
from django.shortcuts import render
 
def home(request):
    List = ['自強學堂', '渲染Json到模板']
    Dict = {'site': '自強學堂', 'author': '塗偉忠'}
    return render(request, 'home.html', {
            'List': json.dumps(List),
            'Dict': json.dumps(Dict)
        })

home.html 只給出了 js 核心部分：

//列表
var List = {{ List|safe }};
//字典
var Dict = {{ Dict|safe }};

固然，你也能夠將 django的模板數據放在html代碼裏，好比你能夠搞一個隱藏的字段

<input type="hidden"/> 把數據扔裏面而後在 js文件去 $("#").val() 去拿數據進行操做，

這樣能夠作到 js代碼與 django代碼分離解耦，適合開發和擴展、調試。

 

原文：http://www.infoq.com/cn/articles/cookie-security

　　在 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、證書管理等安全規範的支持狀況，有待於進一步調查。

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://en.wikipedia.org/wiki/HTTP_cookie
• https://www.owasp.org/index.php/HttpOnly