從0到1完全掌握 CSRF

#本文作者：Drunkbaby，?轉(zhuǎn)載自FreeBuf。

原文鏈接：https://www.freebuf.com/articles/web/333173.html

僅供技術分享交流學習，侵權請聯(lián)系我們刪除。

從0到1完全掌握CSRF

二刷漏洞：知其所以然 -> 知其然 -> 懂其攻 -> 知其守

0x01 前言

總覺得自己的 CSRF 掌握的挺不好的，如今二刷一遍。

當初一刷的時候用的是 Port，而畢竟 Port 嘛，更加注重的是漏洞挖掘，所以當時只是簡單地會用 Burpsuite 當中的 CSRF Poc 而已，其余的原理阿，防御措施阿，都不太懂。

0x02 什么是 CSRF

面試的時候的著名問題："談一談你對 CSRF 與 SSRF 區(qū)別的看法"

這個問題，如果我們用非常通俗的語言講的話，CSRF 更像是釣魚的舉動，是用戶攻擊用戶的；而對于 SSRF 來說，是由服務器發(fā)出請求，用戶日服務器的。

CSRF（Cross-site request forgery）跨站請求偽造：攻擊者誘導受害者進入第三方網(wǎng)站，在第三方網(wǎng)站中，向被攻擊網(wǎng)站發(fā)送跨站請求。利用受害者在被攻擊網(wǎng)站已經(jīng)獲取的注冊憑證，繞過后臺的用戶驗證，達到冒充用戶對被攻擊的網(wǎng)站執(zhí)行某項操作的目的。

在 Port 中，原理圖是這樣的

我們在學習 CSRF 攻擊之前好好先闡述一下它的原理

一個典型的CSRF攻擊有著如下的流程：

• 受害者登錄 a.com，并保留了登錄憑證（Cookie）。

• 攻擊者引誘受害者訪問了 b.com。

• b.com 向 a.com 發(fā)送了一個請求：a.com/act=xx。瀏覽器會默認攜帶 a.com 的 Cookie。

• a.com 接收到請求后，對請求進行驗證，并確認是受害者的憑證，誤以為是受害者自己發(fā)送的請求。

• a.com 以受害者的名義執(zhí)行了 act=xx。

• 攻擊完成，攻擊者在受害者不知情的情況下，冒充受害者，讓 a.com 執(zhí)行了自己定義的操作。

是不是感覺這個工作流程和 XSS 有些類似，但是 XSS 與 CSRF 的最大區(qū)別在于對 Cookie 的使用，XSS 的把受害者 的 Cookie 偷盜過來，而 CSRF 則是借用了受害者的 Cookie。

下面我們舉個例子深化一下 CSRF 的原理。

0x03 CSRF 實戰(zhàn)場景(原理應用)

本段內(nèi)容摘自美團技術團隊文章

這一天，小明同學百無聊賴地刷著 Gmail 郵件。大部分都是沒營養(yǎng)的通知、驗證碼、聊天記錄之類。但有一封郵件引起了小明的注意：

甩賣比特幣，一個只要998！！

聰明的小明當然知道這種肯定是騙子，但還是抱著好奇的態(tài)度點了進去（請勿模仿）。果然，這只是一個什么都沒有的空白頁面，小明失望的關閉了頁面。一切似乎什么都沒有發(fā)生……

在這平靜的外表之下，黑客的攻擊已然得手。小明的 Gmail 中，被偷偷設置了一個過濾規(guī)則，這個規(guī)則使得所有的郵件都會被自動轉(zhuǎn)發(fā)到 [email protected](也就是攻擊方的郵箱)。小明還在繼續(xù)刷著郵件，殊不知他的郵件正在一封封地，如脫韁的野馬一般地，持續(xù)不斷地向著黑客的郵箱轉(zhuǎn)發(fā)而去。

不久之后的一天，小明發(fā)現(xiàn)自己的域名已經(jīng)被轉(zhuǎn)讓了。懵懂的小明以為是域名到期自己忘了續(xù)費，直到有一天，對方開出了 $650 的贖回價碼，小明才開始覺得不太對勁。

小明仔細查了下域名的轉(zhuǎn)讓，對方是擁有自己的驗證碼的，而域名的驗證碼只存在于自己的郵箱里面。小明回想起那天奇怪的鏈接，打開后重新查看了“空白頁”的源碼：

 
	 
	 
	..... 
	 
	 
 

代碼解析 ———— 這也是我們后續(xù)要講到的 CSRF Poc

這個頁面只要打開，就會向Gmail發(fā)送一個post請求。請求中，執(zhí)行了“Create Filter”命令，將所有的郵件，轉(zhuǎn)發(fā)到“[email protected]”。

小明由于剛剛就登陸了Gmail，所以這個請求發(fā)送時，攜帶著小明的登錄憑證（Cookie），Gmail的后臺接收到請求，驗證了確實有小明的登錄憑證，于是成功給小明配置了過濾器。

黑客可以查看小明的所有郵件，包括郵件里的域名驗證碼等隱私信息。拿到驗證碼之后，黑客就可以要求域名服務商把域名重置給自己。

這個頁面只要打開，就會向Gmail發(fā)送一個post請求。請求中，執(zhí)行了“Create Filter”命令，將所有的郵件，轉(zhuǎn)發(fā)到“[email protected]”。

小明由于剛剛就登陸了Gmail，所以這個請求發(fā)送時，攜帶著小明的登錄憑證（Cookie），Gmail的后臺接收到請求，驗證了確實有小明的登錄憑證，于是成功給小明配置了過濾器。

黑客可以查看小明的所有郵件，包括郵件里的域名驗證碼等隱私信息。拿到驗證碼之后，黑客就可以要求域名服務商把域名重置給自己。

0x04 CSRF 的攻擊方式

上文中，我們明晰了一下 CSRF 的攻擊原理，下面我們主講漏洞挖掘。

1. GET 請求產(chǎn)生的 CSRF

GET 請求產(chǎn)生的 CSRF 較為簡單，有 href 攻擊的方式與 HTTP 請求的方式。

GET 請求的 href 類 CSRF

View my Pictures!

在已經(jīng)登錄了bank.com的情況下，當我們點擊 "View my Pictures" 這一鏈接時，就會將錢從一個賬戶轉(zhuǎn)移到另一個賬戶，數(shù)額為 100000

GET 請求的 HTTP 發(fā)包 CSRF

一般會這樣利用：

![](url/withdraw?amount=10000&for=hacker)
 

在受害者訪問含有這個img的頁面后，瀏覽器會自動向
http://bank.example/withdraw/account=xiaoming&amount=10000&for=hacker發(fā)出一次 HTTP 請求。在攻擊者接收到請求的時候我們便可以“借用”對方的 Cookie。

2. POST 請求產(chǎn)生的 CSRF

POST 請求所產(chǎn)生的 CSRF 是我們利用地最多的攻擊方式。

這種類型的 CSRF 利用起來通常使用的是一個自動提交的表單。

訪問該頁面后，表單會自動提交，相當于模擬用戶完成了一次 POST 操作。

POST 類型的攻擊通常比 GET 要求更加嚴格一點，但仍并不復雜。任何個人網(wǎng)站、博客，被黑客上傳頁面的網(wǎng)站都有可能是發(fā)起攻擊的來源，后端接口不能將安全寄托在僅允許 POST 上面。

這里可以通過 Burpsuite 自帶的 CSRF Poc 工具進行攻擊，不過在使用的時候也有一些小技巧。

基礎的 CSRF 攻擊體驗

對應可以嘗試的靶場，在這靶場當中，并沒有添加任意的 CSRF 防御

靶場地址 Lab: CSRF vulnerability with no defenses

因為 CSRF 本質(zhì)上是一種釣魚，所以我們也需要第三方網(wǎng)站攻擊，如自己的服務器，或者 Burpsuite 靶場自帶的 Exploit server；WebGoat 的 WebWolf。

我們先登錄進靶場當中，發(fā)現(xiàn)有一功能點 ———— Update email

試想一下，我們賬號進行了 Update email 的操作。

若我們在自己的服務器上面掛上惡意的 Payload，誘導他人點擊之后。相對應的，對方的郵箱也會變成我們 CSRF Poc 所指定的，這樣子一來，我就可以通過 "忘記密碼" 這種服務來獲取他賬戶的權限了。(當然這里有個前提，對方是登錄過的且 Cookie 處于生效期間)

Exploit 部分

用 Burpsuite 自帶的 CSRF Poc 構(gòu)造出基本框架；

然后我們把這個核心的表單拿出來，并加以修改，構(gòu)造成最后的 POC

再放入到 Exploit Server 當中，點擊 Deliver it to victim 即可。

在對方未對 CSRF 進行任何防御的時候，上述兩種 CSRF 攻擊方式能夠通殺。

懂其攻 -> 知其守

我們現(xiàn)在已經(jīng)知道 CSRF 攻擊方式了，接下來著重講一講 CSRF 的防御手段以及繞過方式。

0x05 CSRF 的防御手段

主流的 CSRF 防御手段有以下兩種

ban 掉不明域外訪問 ———— 使用同源檢測與 Samesite Cookie

多加一層驗證手段 CSRF Token

1. 接近無敵的防御手法 CSRF Token

如果通俗易懂地解釋一下 CSRF Token 的工作原理的話是這樣的。

CSRF Token 每隨著頁面被操作，Token 都會改變，比如 f5 刷新，點擊按鈕等等，都會導致 CSRF Token 變化。

而每一個請求的 CSRF Token 會通過后端代碼驗證 Token 的有效性 ———— 是否正確，在時間戳上是否有效，如果加密字符串一致且時間未過期，那么這個Token就是有效的。

以 Java 為例，我們介紹一下 CSRF Token 服務端的校驗邏輯

HttpServletRequest req = (HttpServletRequest)request; HttpSession s = req.getSession(); 
// 從 session 中得到 csrftoken 屬性 
String sToken = (String)s.getAttribute(“csrftoken”); if(sToken == null) { 
	// 產(chǎn)生新的 token 放入 session 中 
	sToken = generateToken(); s.setAttribute(“csrftoken”,sToken); chain.doFilter(request, response); 
}
else { 
	// 從 HTTP 頭中取得 csrftoken 
	String xhrToken = req.getHeader(“csrftoken”); 
	// 從請求參數(shù)中取得 csrftoken 
	String pToken = req.getParameter(“csrftoken”); 
	if(sToken != null && xhrToken != null && sToken.equals(xhrToken)){ 
		chain.doFilter(request, response); 
	}
	else if(sToken != null && pToken != null && sToken.equals(pToken)){ 
		chain.doFilter(request, response); 
	}
	else
	{ request.getRequestDispatcher(“error.jsp”).forward(request,response); 
	} 
}

2. 用的較少的限制同源

Samesite 是 Set-Cookie 的一種屬性，它有三個值

Strict最為嚴格，完全禁止第三方 Cookie，跨站點時，任何情況下都不會發(fā)送 Cookie。換言之，只有當前網(wǎng)頁的 URL 與請求目標一致，才會帶上 Cookie。

Set-Cookie: CookieName=CookieValue; SameSite=Strict;

Lax規(guī)則稍稍放寬，大多數(shù)情況也是不發(fā)送第三方 Cookie，但是導航到目標網(wǎng)址的 Get 請求除外。

Set-Cookie: CookieName=CookieValue; SameSite=Lax;

還有一種屬性為None，這種屬性代表關閉了SameSite

一般攻擊要進行繞過可以嘗試將 SameSite 設置為 None

這種方法的原理也比較簡單，因為 CSRF 的本質(zhì)也是釣魚，比如我通過郵箱發(fā)送釣魚郵件，那么這時候的 "源" 就是郵箱界面。

如果服務器設置了嚴格的同源政策，將不接收來自郵箱這一 "源" 的請求。

ok，講完了常規(guī)的防御手段，接下來我們聊聊繞過

0x06 針對 CSRF Token 與同源政策的繞過手段

我們的繞過手段是基于 CSRF Token 或同源政策并不是那么嚴格的情況下，甚至某些時候由于設計的疏忽產(chǎn)生的邏輯漏洞。

若非特別提醒，以下所有靶場的業(yè)務點均處于?"Update email"下。

1. 將 POST 修改為 GET 請求進行繞過

靶場地址 Lab: CSRF where token validation depends on request method)

背后邏輯：

CSRF Token 在 POST 請求當中生效，且業(yè)務點并非完全限制請求為 POST 請求，從而給了攻擊者進行繞過的機會。

探測方法：將 CSRF Token 刪掉，并將 HTTP 請求修改為 GET 請求。

此時的回顯為"Missing parameter 'csrf'"，我們再將 HTTP 請求修改為 GET 請求，觀察回顯。

回顯 302，代表我們可以用這種方式進行繞過，構(gòu)造 Payload

2. 刪除 CSRF Token 進行繞過

靶場地址 Lab: CSRF where token validation depends on token being present

背后邏輯:

并沒有強驗證 CSRF Token 的存在性。

我們嘗試刪除 CSRF Token，回顯 302

在刪除掉 CSRF Token 之后生成 POC 即可。

3. CSRF Token 未與用戶 Session 綁定

靶場地址 Lab: CSRF where token is not tied to user session

背后邏輯

未進行嚴格的一一身份對應，這其實很好理解。舉個例子，我們登錄注冊界面，實際上是需要去匹配用戶名與密碼是否相等的，而這里的邏輯也是一致。

那么這里，我可以先修改 Cookie，再修改 CSRF Token，來觀察 CSRF Token 與 Cookie 是否對應了，或者說是否綁定了。

修改 Cookie 中的 Session 值，觀察回顯為 "Unauthorized"

修改 CSRF Token，觀察回顯為 "Invalid CSRF Token"

說明 CSRF Token 并未與 session 綁定，而是與 csrfKey(也就是 value) 綁定的，根據(jù) cookie 的傳遞性，我們可以在其他頁面提前把 csrfKey 注入進去，這里我們利用img與onerror組合的 XSS 以及 CLRF 技術來構(gòu)造 CSRF。

這里借用梨子師傅的 Poc

當受害者點擊 CSRF 鏈接時會先觸發(fā) CLRF 注入 Set-Cookie 參數(shù)值，將 csrfKey 值添加到 Cookie 中，然后再用附有與 csrfKey 對應的 CSRF Token 的請求去提交修改郵箱請求。

4. 當 Cookie 中的 CSRF 值與 CSRF Token 的值一致時

靶場地址 Lab: CSRF where token is duplicated in cookie

背后邏輯：

只是將 CSRF Token 簡單復制到 cookie 頭中，然后僅驗證兩者是否一致。

所以這里我們的繞過 Poc 的核心部分應該是這樣的,%0d%0a為\r\n，也就是 CR 與 LF

5. 對不嚴格的 Referer 限制進行繞過

靶場地址 Lab: CSRF with broken Referer validation

背后邏輯

并沒有特別嚴格地限制 Referer，僅僅只是不允許了這一種的 Referer。

Referer: 靶場地址.com

// 下面是非法的

Referer: baidu.com

一般我們通過Referer: baidu.com來判斷 Referer 的限制。

若Referer: baidu.com被限制，則我們可以通過這種方式進行繞過

http://attacker-website.com/csrf-attack?baidu.com

靶場部分，同樣是對更改郵箱這個功能點進行 CSRF 攻擊

這里我們需要介紹一下history.pushState，這個函數(shù)顧名思義，就是插入歷史記錄的，所以這也就是為什么第三個參數(shù)的值修改為與攻擊鏈接同源后即可繞過錯誤地 Referer 頭驗證機制，所以我們這樣構(gòu)造 CSRF 頁面。

我們先修改 Referer 為 baidu.com 查看回顯，成功發(fā)包。

修改 Referer 為baidu.com+?laburl，回顯為 302 成功。

構(gòu)造 Payload，將history.pushState的第三個參數(shù)修改為 Lab 的 URL 地址。投放之后，在 Head 當中添加Referrer-Policy: unsafe-url

0x07 小結(jié)

CSRF 攻擊本質(zhì)上還是一種釣魚手段，本文著重講了一些 CSRF 攻擊的繞過手法，說不定滲透的時候多試一試就能起到意想不到的效果。