一.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攻擊，受害者必須依次完成兩個步驟：
登錄受信任網站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的代碼如下：
<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去獲取請求的數據，而$_REQUEST既可以獲取GET請求的數據，也可以獲取POST請求的數據，這就造成了在後臺處理程序無法區分這到底是GET請求的數據還是POST請求的數據。在PHP中，可以使用$_GET和$_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的身份驗證機制雖然可以保證一個請求是來自於某個用戶的瀏覽器，但卻無法保證該請求是用戶批准發送的！
五.CSRF的防禦
我總結了一下看到的資料，CSRF的防禦可以從服務端和客戶端兩方面著手，防禦效果是從服務端著手效果比較好，現在一般的CSRF防禦也都在服務端進行。
1.服務端進行CSRF防禦
服務端的CSRF方式方法很多樣，但總的思想都是一致的，就是在客戶端頁面增加偽隨機數。
(1).Cookie Hashing(所有表單都包含同一個偽隨機值)：
這可能是最簡單的解決方案了，因為攻擊者不能獲得第三方的Cookie(理論上)，所以表單中的數據也就構造失敗了:>
<?php
//構造加密的Cookie信息
$value = 「DefenseSCRF」;
setcookie(」cookie」, $value, time()+3600);
?>
在表單裡增加Hash值，以認證這確實是用戶發送的請求。
<?php
$hash = md5($_COOKIE['cookie']);
?>
<form method=」POST」 action=」transfer.php」>
<input type=」text」 name=」toBankId」>
<input type=」text」 name=」money」>
<input type=」hidden」 name=」hash」 value=」<?=$hash;?>」>
<input type=」submit」 name=」submit」 value=」Submit」>
</form>
然後在伺服器端進行Hash值驗證
<?php
if(isset($_POST['check'])) {
$hash = md5($_COOKIE['cookie']);
if($_POST['check'] == $hash) {
doJob();
} else {
//...
}
} else {
//...
}
?>
這個方法個人覺得已經可以杜絕99%的CSRF攻擊了，那還有1%呢....由於用戶的Cookie很容易由於網站的XSS漏洞而被盜取，這就另外的1%。一般的攻擊者看到有需要算Hash值，基本都會放棄了，某些除外，所以如果需要100%的杜絕，這個不是最好的方法。
(2).驗證碼
這個方案的思路是：每次的用戶提交都需要用戶在表單中填寫一個圖片上的隨機字符串，厄....這個方案可以完全解決CSRF，但個人覺得在易用性方面似乎不是太好，還有聽聞是驗證碼圖片的使用涉及了一個被稱為MHTML的Bug，可能在某些版本的微軟IE中受影響。
(3).One-Time Tokens(不同的表單包含一個不同的偽隨機值)
在實現One-Time Tokens時，需要注意一點：就是「並行會話的兼容」。如果用戶在一個站點上同時打開了兩個不同的表單，CSRF保護措施不應該影響到他對任何表單的提交。考慮一下如果每次表單被裝入時站點生成一個偽隨機值來覆蓋以前的偽隨機值將會發生什麼情況：用戶只能成功地提交他最後打開的表單，因為所有其他的表單都含有非法的偽隨機值。必須小心操作以確保CSRF保護措施不會影響選項卡式的瀏覽或者利用多個瀏覽器窗口瀏覽一個站點。
以下我的實現:
1).先是令牌生成函數(gen_token())：
<?php
function gen_token() {
//這裡我是貪方便，實際上單使用Rand()得出的隨機數作為令牌，也是不安全的。
//這個可以參考我寫的Findbugs筆記中的《Random object created and used only once》
$token = md5(uniqid(rand(), true));
return $token;
}
2).然後是Session令牌生成函數(gen_stoken())：
<?php
function gen_stoken() {
$pToken = "";
if($_SESSION[STOKEN_NAME] == $pToken){
//沒有值，賦新值
$_SESSION[STOKEN_NAME] = gen_token();
}
else{
//繼續使用舊的值
}
}
?>
3).WEB表單生成隱藏輸入域的函數：
<?php
function gen_input() {
gen_stoken();
echo 「<input type=\」hidden\」 name=\」" . FTOKEN_NAME . 「\」
value=\」" . $_SESSION[STOKEN_NAME] . 「\」> 「;
}
?>
4).WEB表單結構：
<?php
session_start();
include(」functions.php」);
?>
<form method=」POST」 action=」transfer.php」>
<input type=」text」 name=」toBankId」>
<input type=」text」 name=」money」>
<? gen_input(); ?>
<input type=」submit」 name=」submit」 value=」Submit」>
</FORM>
5).服務端核對令牌：
這個很簡單，這裡就不再囉嗦了。
上面這個其實不完全符合「並行會話的兼容」的規則，大家可以在此基礎上修改。
轉載自segmentfault
關注我們吧！