什麼是CSRF
CSRF（Cross-siterequestforgery跨站請求僞造，也被稱爲“oneclickattack”或者sessionriding，通常縮寫爲CSRF或者XSRF，是一種對網站的惡意利用。儘管聽起來像跨站腳本（XSS），但它與XSS非常不同，並且***方式幾乎相左。XSS利用站點內的信任用戶，而CSRF則通過僞裝來自受信任用戶的請求來利用受信任的網站。與XSS***相比，CSRF***往往不大流行（因此對其進行防範的資源也相當稀少）和難以防範，所以被認爲比XSS更具危險性。
Xss與CSRF異同
CSRF與XSS在***手段上有點類似，都是在客戶端執行惡意代碼，有些文章中認爲CSRF與XSS的區別在於CSRF不注重於獲取用戶Cookie，筆者認爲可能還有區別在於CSRF不僅可以在源站發起***，還可以引導用戶訪問其他危險網站的同時發起***。
XSS全程是跨站腳本***，即***者向某個Web頁面中插入惡意的JavaScript腳本。而當普通用戶訪問時，該惡意腳本自動執行而從盜取用戶的Cookie等信息。對於XSS的防禦手段主要就是輸入檢查與輸出檢查，譬如對用戶輸入的文本框內容進行<、>這樣的特殊字符檢查。而輸出檢查則是指對於輸出到網頁的內容進行過濾或者編解碼，譬如使用HTML編碼將<轉義。
CSRF爲跨站請求僞造，其與XSS有點類似，不過區別在於CSRF不一定依賴於JavaScript，並且不僅可以在源站發起***，還有可能當用戶訪問惡意網站時引導其訪問原網站。CSRF***是源於WEB的隱式身份驗證機制，WEB的身份驗證機制雖然可以保證一個請求是來自於某個用戶的瀏覽器，但卻無法保證該請求是用戶批准發送的。對於CSRF的防禦也分爲服務端防禦與客戶端防禦兩種，服務端防禦典型的譬如給某個頁面添加隨機數，使得無法從第三方頁面直接提交。在客戶端防禦的話可以利用譬如Firefox提供的一些檢查工具。注意，CSRF並沒有打破同源策略。
CSRF的危害
你這可以這麼理解CSRF***：***者盜用了你的身份，以你的名義發送惡意請求。CSRF能夠做的事情包括：以你名義發送郵件，發消息，盜取你的賬號，甚至於購買商品，
虛擬貨幣轉賬等等造成的問題包括：個人隱私泄露以及財產安全。
下圖簡單闡述了CSRF***的思想：
從上圖可以看出，要完成一次CSRF***，受害者必須依次完成兩個步驟：
1.登錄受信任網站A，並在本地生成Cookie。
2.在不登出A的情況下，訪問危險網站B。
看到這裏，你也許會說：“如果我不滿足以上兩個條件中的一個，我就不會受到CSRF的***”。是的，確實如此，但你不能保證以下情況不會發生：
1.你不能保證你登錄了一個網站後，不再打開一個tab頁面並訪問另外的網站。
2.你不能保證你關閉瀏覽器了後，你本地的Cookie立刻過期，你上次的會話已經結束。（事實上，關閉瀏覽器不能結束一個會話，但大多數人都會錯誤的認爲關閉瀏覽器就等於退出登錄/結束會話了......）
3.上圖中所謂的***網站，可能是一個存在其他漏洞的可信任的經常被人訪問的網站。同樣也可以是一個惡意的url。
SCRF觸發條件
1、被***者的用戶cookies
2、惡意的url或表單
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值驗證
<?phpif(isset($_POST['check'])) {
$hash =md5($_COOKIE['cookie']);
if($_POST['check'] == $hash) {
doJob();
} else {
//...
}
} else {
//...
}
?>
這個方法目前覺得已經可以杜絕大多數***了，那還有少數由於用戶的Cookie很容易由於網站的XSS漏洞而被盜取，一般的***者看到有需要算Hash值，基本都會放棄了，當然也有些人除外，所以如果需要100%的杜絕，這並不是最好的方法。
(2).驗證碼
這個方案的思路是：每次的用戶提交都需要用戶在表單中填寫一個圖片上的隨機字符串，厄....這個方案可以完全解決CSRF，但個人覺得在易用性方面似乎不是太好，還有聽聞是驗證碼圖片的使用涉及了一個被稱爲MHTML的Bug，可能在某些版本的微軟IE中受影響。
(3).One-Time Tokens(不同的表單包含一個不同的僞隨機值)
在實現One-Time Tokens時，需要注意一點：就是“並行會話的兼容”。如果用戶在一個站點上同時打開了兩個不同的表單，CSRF保護措施不應該影響到他對任何表單的提交。考慮一下如果每次表單被裝入時站點生成一個僞隨機值來覆蓋以前的僞隨機值將會發生什麼情況：用戶只能成功地提交他最後打開的表單，因爲所有其他的表單都含有非法的僞隨機值。必須小心操作以確保CSRF保護措施不會影響選項卡式的瀏覽或者利用多個瀏覽器窗口瀏覽一個站點。
以下我的實現:
1).先是令牌生成函數(gen_token())：
<?phpfunction gen_token() {
$token = md5(uniqid(rand(), true));
return $token;
}
2).然後是Session令牌生成函數(gen_stoken())：
<?phpfunction gen_stoken() {
$pToken = "";
if($_SESSION[STOKEN_NAME] == $pToken){
//沒有值，賦新值
$_SESSION[STOKEN_NAME] =gen_token();
}
else{
//繼續使用舊的值
}
}
?>
3).WEB表單生成隱藏輸入域的函數：
<?phpfunction gen_input() {
gen_stoken();
echo “<input type=\”hidden\” name=\”" . FTOKEN_NAME . “\”
value=\”". $_SESSION[STOKEN_NAME] . “\”> “;
}
?>
4).WEB表單結構：
<?phpsession_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).服務端覈對令牌