带你刷burpsuite官方网络安全学院靶场(练兵场)之客户端漏洞——跨站请求伪造(CSRF)专题
介紹
PortSwigger是信息安全從業者必備工具burpsuite的發行商，作為網絡空間安全的領導者，他們為信息安全初學者提供了一個在線的網絡安全學院(也稱練兵場)，在講解相關漏洞的同時還配套了相關的在線靶場供初學者練習，本系列旨在以梨子這個初學者視角出發對學習該學院內容及靶場練習進行全程記錄并為其他初學者提供學習參考，希望能對初學者們有所幫助。
什么是CSRF？
CSRF全稱為cross-site request forgery，譯為跨站請求偽造。有的站點會采用同源策略，如果想要利用受害者身份去執行惡意操作需要攻擊者誘使受害者提交那個惡意請求，也就是借刀殺人。
CSRF是如何運作的？
成功發動CSRF攻擊有三個因素
- 一個相關的操作，即你想利用CSRF讓受害者干什么，比如權限操作、修改數據等
- 基于cookie的會話處理，cookie是唯一能夠通過document.cookie()函數直接獲取到的可以用來進行會話處理的字段，所以要想成功發動CSRF需要那個應用程序僅通過cookie進行會話處理。
- 沒有不可預測的參數，因為CSRF攻擊是要提前構造請求的，所以如果需要填寫一些不可預測的參數，如密碼，就不能成功發動CSRF
假如某個應用程序存在一個功能點可以修改郵箱地址，會發出這樣的請求
POST /email/change HTTP/1.1 Host: vulnerable-website.com Content-Type: application/x-www-form-urlencoded Content-Length: 30 Cookie: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfEemail=wiener@normal-user.com根據上面講的三個要素，這個功能點是可以成功發動CSRF的，因為它可以執行攻擊者感興趣的操作(修改郵箱)，然后僅通過cookie來進行會話處理，而且參數只有一個email，所以是可以成功發動CSRF的。這樣我們就可以構造這樣的CSRF頁面去觸發它。
<html><body><form action="https://vulnerable-website.com/email/change" method="POST"><input type="hidden" name="email" value="pwned@evil-user.net" /></form><script>document.forms[0].submit();</script></body> </html>當我們把這個CSRF頁面投放到受害者那里時會因為document.forms[0].submit()自動提交一個POST表單請求，同時會自動使用受害者的Cookie發送，即表示由受害者自主提交的修改郵箱請求。
如何構造一個CSRF攻擊？
首先我們找到想要用來構造CSRF的請求，然后在burp中右鍵Engagement tools / Generate CSRF PoC，然后就會自動生成一個CSRF頁面了。
配套靶場：無防護的CSRF漏洞
前面介紹過，我們需要先登錄給定的用戶抓取修改郵箱的請求包
我們看到這個功能還是很好用的，可以自動生成CSRF頁面，然后我們將其復制到Exploit Server投放給受害者，就能成功修改其郵箱地址了。
如何利用CSRF？
在XSS專題中其實我們已經有所提及了，img會自動向src屬性指定的域名發出請求，有的應用程序允許通過發送GET請求修改郵箱地址，所以我們可以將src設置為帶有GET參數的CSRF URL，當加載該img時即會觸發CSRF。
XSS和CSRF有什么區別？
XSS是可以允許攻擊者在受害者瀏覽器執行任意JS腳本，而CSRF是允許攻擊者誘使受害者執行他們本不打算執行的操作。相比之下，XSS的危害更大，因為XSS能夠執行任意JS腳本，包括發送一些請求，而CSRF只能執行沒有實施CSRF防護的功能。XSS可以將結果發送到遠程服務器接收，而CSRF只能發出請求而已。
CSRF Token可以用來緩解XSS嗎？
CSRF Token確實可以緩解一些XSS攻擊，比如考慮這樣的一個XSS payload
https://insecure-website.com/status?message=<script>/*+Bad+stuff+here...+*/</script>我們在引入了CSRF Token之后就可以用來緩解這樣的XSS攻擊
https://insecure-website.com/status?csrf-token=CIwNZNlR4XbisJF39I8yWnWX9wX4WFoz&message=<script>/*+Bad+stuff+here...+*/</script>應用程序會驗證CSRF Token，如果是無效的就會拒絕這個請求。但是CSRF Token不能緩解存儲型XSS攻擊。
CSRF Token
什么是CSRF Token？
CSRF Token是一個唯一的、保密的、不可預測的字符串，它由服務器端生成然后包含在后續的請求中。當服務器端接收到請求后會驗證CSRF Token，如果其已經失效則會拒絕該請求。這就打破了可以成功構造CSRF的三個因素了，即參數不可預測，所以可以用來緩解CSRF攻擊。
CSRF Token應該怎樣生成？
CSRF Token應該具有高度地不可預測性，可以使用高強度的偽隨機數生成器(PRNG)，并且以時間戳加上靜態密鑰作為其種子。如果想要更高的不可預測性，我們可以將隨機數與用戶的個人標識信息組合，然后再整體做一個哈希處理。
CSRF Token應該怎樣傳輸？
一般情況，服務器會通過隱藏字段傳輸給客戶端，然后在提交表單的時候自動加進去。在XSS專題中我們介紹了利用懸掛標記攻擊獲取CSRF Token的攻擊手段，所以我們應該把該字段放在表單最前面。并且盡量不要以GET請求參數和請求標頭的方式傳輸。
CSRF Token應該怎樣驗證？
應該在服務器端建立CSRF Token與用戶會話的綁定關系，當接收到某個請求時，驗證請求中的CSRF Token是否與所綁定的用戶會話匹配，不匹配則拒絕該請求。
使用SameSite cookie緩解CSRF攻擊
什么是SameSite cookie？
SameSite是cookie字段的一個屬性，用于定義跨站請求的提交方式，以防止瀏覽器對于任意來源的請求都自動填充cookie
SameSite有哪些不同的值，作用是什么？
SameSite=Strict
當SameSite被設置為這個值時，瀏覽器將不會對第三方網站自動填充cookie，但是有一個缺點就是普通用戶需要重新登錄一次
SameSite=Lax
當SameSite被設置成這個值時，瀏覽器雖然會自動填充cookie，但是有兩個條件
- 請求方法為GET(除此之外的方法不會自動填充)
- 請求來自頂級框架(除此之外的請求不會自動填充)
但是有的網站也會通過GET請求方法去進行一些敏感操作，所以不太建議僅利用SameSite來進行防御CSRF攻擊，一般會搭配CSRF Token組合防御
常見的CSRF漏洞
依賴請求方法的CSRF驗證
有的應用系統僅會驗證POST請求中的CSRF Token，但是不會驗證GET請求下的，這時候會跳過驗證
配套靶場：依賴請求方法的CSRF Token驗證
首先我們將正常修改郵箱請求中的CSRF Token去掉觀察一下會發生什么
看到會提示缺少參數，但是如果我們右鍵change request method將POST請求轉換成GET請求再觀察一下
發現居然不需要CSRF Token參數就可以，說明我們成功發動了CSRF
依賴CSRF Token是否存在的CSRF驗證
有的應用系統僅會在請求中存在CSRF Token的情況下對其進行驗證，如果不存在該參數則不會進行驗證
配套靶場：依賴CSRF Token是否存在的CSRF驗證
知識點講的很清楚，當我們去掉請求中的CSRF Token參數時即不會驗證該字段
發現可以成功發動CSRF
CSRF Token未與用戶會話綁定
有的應用系統僅會驗證CSRF Token的有效性，而不會驗證該Token是否屬于當前用戶，即不會與用戶會話綁定
配套靶場：CSRF Token未與用戶會話綁定
因為CSRF Token未與用戶會話綁定，所以我們只需要一個有效的CSRF Token就可以，于是我們登錄測試用戶，然后抓取修改郵箱的請求包，制作成CSRF頁面，再將這個包丟掉，將這個頁面利用Exploit Server投放給受害者。
因為CSRF Token是有效的，所以是可以成功發動CSRF的
CSRF Token與非會話cookie綁定
有的應用系統雖然將CSRF Token與Cookie中某個參數值綁定了，但是并沒有與session這個Cookie參數綁定，這樣還是會導致CSRF Token與綁定的參數組合可以被任意用戶用于請求。
在構造CSRF POC有一個比較有趣的操作，需要在用burp生成CSRF鏈接的時候將自動提交標簽改成img標簽，將提交表單事件設置在onerror屬性中，將利用CLRF注入Cookie的頁面設置在src屬性中。(注：應用Set-Cookie參數值注入Cookie)
配套靶場：CSRF Token與非會話cookie綁定
首先我們修改一下cookie中的session，觀察一下
發現修改了session以后只是會提示未登錄，那么我們修改一下csrfKey參數的值呢
說明CSRF Token并未與session綁定，而是與csrfKey綁定的，根據cookie的傳遞性，我們可以在其他頁面提前把csrfKey注入進去，這里我們利用img與onerror組合的XSS以及CLRF技術來構造CSRF
當受害者點擊CSRF鏈接時會先觸發CLRF注入Set-Cookie參數值將csrfKey值添加到Cookie中，然后再用附有與csrfKey對應的CSRF Token的請求去提交修改郵箱請求
CSRF Token被簡單復制到cookie中
有的應用程序偷工減料，僅將CSRF Token簡單復制到cookie頭中，然后僅驗證兩者是否一致，這樣很容易通過驗證
配套靶場：CSRF Token被簡單復制到cookie中
經過測試，使用測試用戶提交的修改郵箱請求中的CSRF Token可以無限次使用，所以我們直接由此構造CSRF頁面
將該頁面投放到受害者之后即可觸發CSRF
基于Referer抵御CSRF攻擊
基于Referer頭的防護原理就是檢查請求的來源是不是屬于該應用程序的域，不過防護效果較差
依賴頭部是否存在的Referer驗證
這種驗證手段與之前的類似，即Referer存在即驗證，不存在即不驗證，通過以下模板來構造CSRF頁面
<meta name="referrer" content="no-referrer">配套靶場：依賴頭部是否存在的Referer驗證
與前面的CSRF驗證類似，只不過CSRF頁面語句不太一樣
這樣就不會自動在請求中加入referer字段，從而繞過驗證
錯誤地驗證Referer
有的時候僅驗證Referer頭中是否包含預期域名，而不驗證是否有其他不可信域名在里面，所以我們可以構造這樣奇葩的URL
http://vulnerable-website.com.attacker-website.com/csrf-attack http://attacker-website.com/csrf-attack?vulnerable-website.com有的瀏覽器會將Referer中的查詢字符串拆出來，所以我們可以添加Referrer-Policy: unsafe-url這樣的頭部字段以保證不會被拆出來
配套靶場：錯誤地驗證Referer
這里我們需要介紹一下history.pushState，這個函數顧名思義，就是插入歷史記錄的，所以這也就是為什么第三個參數的值修改為與攻擊鏈接同源后即可繞過錯誤地Referer頭驗證機制，所以我們這樣構造CSRF頁面
這樣我們就可以繞過驗證Referer來發動CSRF了
總結
以上就是 帶你刷burpsuite官方網絡安全學院靶場(練兵場)系列之客戶端漏洞篇 – 跨站請求偽造(CSRF)專題的全部內容啦，本專題主要講了CSRF的形成原理、常見的利用、防護、防護的繞過等，感興趣的同學可以在評論區進行討論，嘻嘻嘻。
相對于服務器端漏洞篇，客戶端漏洞篇會更加復雜，需要在我們之前學過的服務器篇的基礎上去利用。
最后
如果有想學但是還不知道怎么入手學網絡安全的朋友或者是需要晉升漲工資的朋友可以關注我
call me 我這整理了相關的學習資料！！！
總結
以上是生活随笔為你收集整理的带你刷burpsuite官方网络安全学院靶场(练兵场)之客户端漏洞——跨站请求伪造(CSRF)专题的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 【安全漏洞】黑客利用IE 0 day漏洞
- 下一篇： 【安全漏洞】CVE-2020-26567