有關網路攻擊的CSRF

阿新 • • 發佈：2019-01-16

最近在工作做一個SSO，考慮很多網路安全方面的問題，看到一篇好文章，分享給大家：

一.CSRF是什麼？

　　CSRF（Cross-site request forgery），中文名稱：跨站請求偽造，也被稱為：one click attack/session riding，縮寫為：CSRF/XSRF。

二.CSRF可以做什麼？

　　你這可以這麼理解CSRF攻擊：攻擊者盜用了你的身份，以你的名義傳送惡意請求。CSRF能夠做的事情包括：以你名義傳送郵件，發訊息，盜取你的賬號，甚至於購買商品，虛擬貨幣轉賬......造成的問題包括：個人隱私洩露以及財產安全。

三.CSRF漏洞現狀

　　CSRF這種攻擊方式在2000年已經被國外的安全人員提出，但在國內，直到06年才開始被關注，08年，國內外的多個大型社群和互動網站分別爆出CSRF漏洞，如：NYTimes.com（紐約時報）、Metafilter（一個大型的BLOG網站），YouTube和百度HI......而現在，網際網路上的許多站點仍對此毫無防備，以至於安全業界稱CSRF為“沉睡的巨人”。

四.CSRF的原理

　　下圖簡單闡述了CSRF攻擊的思想：

　　從上圖可以看出，要完成一次CSRF攻擊，受害者必須依次完成兩個步驟：

　　1.登入受信任網站A，並在本地生成Cookie。

　　2.在不登出A的情況下，訪問危險網站B。

　　看到這裡，你也許會說：“如果我不滿足以上兩個條件中的一個，我就不會受到CSRF的攻擊”。是的，確實如此，但你不能保證以下情況不會發生：

　　1.你不能保證你登入了一個網站後，不再開啟一個tab頁面並訪問另外的網站。

　　2.你不能保證你關閉瀏覽器了後，你本地的Cookie立刻過期，你上次的會話已經結束。（事實上，關閉瀏覽器不能結束一個會話，但大多數人都會錯誤的認為關閉瀏覽器就等於退出登入/結束會話了......）

　　3.上圖中所謂的攻擊網站，可能是一個存在其他漏洞的可信任的經常被人訪問的網站。

　　上面大概地講了一下CSRF攻擊的思想，下面我將用幾個例子詳細說說具體的CSRF攻擊，這裡我以一個銀行轉賬的操作作為例子（僅僅是例子，真實的銀行網站沒這麼傻:>）

　　示例1：

　　銀行網站A，它以GET請求來完成銀行轉賬的操作，如：http://www.mybank.com/Transfer.php?toBankId=11&money=1000

　　危險網站B，它裡面有一段HTML的程式碼如下：

[html] view plain copy print ?

<imgsrc=

http://www.mybank.com/Transfer.php?toBankId=11&money=1000>

首先，你登入了銀行網站A，然後訪問危險網站B，噢，這時你會發現你的銀行賬戶少了1000塊......

　　為什麼會這樣呢？原因是銀行網站A違反了HTTP規範，使用GET請求更新資源。在訪問危險網站B的之前，你已經登入了銀行網站A，而B中的<img>以GET的方式請求第三方資源（這裡的第三方就是指銀行網站了，原本這是一個合法的請求，但這裡被不法分子利用了），所以你的瀏覽器會帶上你的銀行網站A的Cookie發出Get請求，去獲取資源“http://www.mybank.com/Transfer.php?toBankId=11&money=1000”，結果銀行網站伺服器收到請求後，認為這是一個更新資源操作（轉賬操作），所以就立刻進行轉賬操作......

　　示例2：

　　為了杜絕上面的問題，銀行決定改用POST請求完成轉賬操作。

　　銀行網站A的WEB表單如下：

[html] view plain copy print ?

<formaction="Transfer.php"method="POST">
　　<p>ToBankId: <inputtype="text"name="toBankId"/></p>
　　<p>Money: <inputtype="text"name="money"/></p>
　　<p><inputtype="submit"value="Transfer"/></p>
</form>

後臺處理頁面Transfer.php如下：

[php] view plain copy print ?

<?php
　　　　session_start();
　　　　if (isset($_REQUEST['toBankId'] &&　isset($_REQUEST['money']))
　　　　{
　　　　 buy_stocks($_REQUEST['toBankId'],　$_REQUEST['money']);
　　　　}
　　?>

危險網站B，仍然只是包含那句HTML程式碼：

[html] view plain copy print ?

<imgsrc=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>

和示例1中的操作一樣，你首先登入了銀行網站A，然後訪問危險網站B，結果.....和示例1一樣，你再次沒了1000塊～T_T，這次事故的原因是：銀行後臺使用了$_REQUEST去獲取請求的資料，而$_REQUEST既可以獲取GET請求的資料，也可以獲取POST請求的資料，這就造成了在後臺處理程式無法區分這到底是GET請求的資料還是POST請求的資料。在PHP中，可以使用$_GET和$_POST分別獲取GET請求和POST請求的資料。在JAVA中，用於獲取請求資料request一樣存在不能區分GET請求資料和POST資料的問題。

　　示例3：

　　經過前面2個慘痛的教訓，銀行決定把獲取請求資料的方法也改了，改用$_POST，只獲取POST請求的資料，後臺處理頁面Transfer.php程式碼如下：

[php] view plain copy print ?

<?php
　　　　session_start();
　　　　if (isset($_POST['toBankId'] &&　isset($_POST['money']))
　　　　{
　　　　 buy_stocks($_POST['toBankId'],　$_POST['money']);
　　　　}
　　?>

然而，危險網站B與時俱進，它改了一下程式碼：

[php] view plain copy print ?

<html>
　　<head>
　　　　<script type="text/javascript">
　　　　　　function steal()
　　　　　　{
　　　　 iframe = document.frames["steal"];
　　　　 iframe.document.Submit("transfer");
　　　　　　}
　　　　</script>
　　</head>
　　<body onload="steal()">
　　　　<iframe name="steal" display="none">
　　　　　　<form method="POST" name="transfer"　action="http://www.myBank.com/Transfer.php">
　　　　　　　　<input type="hidden" name="toBankId" value="11">
　　　　　　　　<input type="hidden" name="money" value="1000">
　　　　　　</form>
　　　　</iframe>
　　</body>
</html>

如果使用者仍是繼續上面的操作，很不幸，結果將會是再次不見1000塊......因為這裡危險網站B暗地裡傳送了POST請求到銀行!

　　總結一下上面3個例子，CSRF主要的攻擊模式基本上是以上的3種，其中以第1,2種最為嚴重，因為觸發條件很簡單，一個<img>就可以了，而第3種比較麻煩，需要使用JavaScript，所以使用的機會會比前面的少很多，但無論是哪種情況，只要觸發了CSRF攻擊，後果都有可能很嚴重。

　　理解上面的3種攻擊模式，其實可以看出，CSRF攻擊是源於WEB的隱式身份驗證機制！WEB的身份驗證機制雖然可以保證一個請求是來自於某個使用者的瀏覽器，但卻無法保證該請求是使用者批准傳送的！

有關網路攻擊的CSRF

有關網路攻擊的CSRF

有關網路攻擊的世界地圖是怎麼開發的？比如 ZoomEye 經常有一些這樣很酷的地圖~

網路攻擊與防禦技術第三次實驗

軟體完整性有助於金融服務機構抵禦網路攻擊

網路攻擊與防禦技術第四次實驗

網路攻擊與防禦技術第五次實驗

Linux 下的網路攻擊

曲速未來揭示：強大網路攻擊冰島於複雜網路釣魚形式

有關網路流建模的學習筆記

網路攻擊網路支付

使用Spark Mlib K-Means演算法分析網路攻擊資料

幾維安全CEO範俊偉：對程式碼進行加密或能更有效應對網路攻擊

網路攻擊形式備忘錄

萬方+網路攻擊+機器學習

常見網路攻擊案例

區塊鏈安全：基於區塊鏈網路攻擊的方式原理詳解

網路攻擊型別

針對美國智庫、非盈利和公共組織的網路攻擊分析

青松資訊：你家那臺路由器，很可能是網路攻擊的幫凶！

又出現新型網路攻擊主要受害物件為Hadoop伺服器

有關網路攻擊的CSRF

相關推薦