一.CSRF是什么放祟？
CSRF（Cross-site request forgery），中文名稱：跨站請(qǐng)求偽造鹅髓，也被稱為：one click attack/session riding舞竿，縮寫為：CSRF/XSRF。
二.CSRF可以做什么窿冯？
你這可以這么理解CSRF攻擊：攻擊者盜用了你的身份骗奖，以你的名義發(fā)送惡意請(qǐng)求。CSRF能夠做的事情包括：以你名義發(fā)送郵件醒串，發(fā)消息执桌，盜取你的賬號(hào)，甚至于購買商品芜赌，虛擬貨幣轉(zhuǎn)賬......造成的問題包括：個(gè)人隱私泄露以及財(cái)產(chǎn)安全仰挣。
三.CSRF漏洞現(xiàn)狀
CSRF這種攻擊方式在2000年已經(jīng)被國(guó)外的安全人員提出，但在國(guó)內(nèi)缠沈，直到06年才開始被關(guān)注膘壶，08年错蝴，國(guó)內(nèi)外的多個(gè)大型社區(qū)和交互網(wǎng)站分別爆出CSRF漏洞，如：NYTimes.com（紐約時(shí)報(bào)）颓芭、Metafilter（一個(gè)大型的BLOG網(wǎng)站）顷锰，YouTube和百度HI......而現(xiàn)在，互聯(lián)網(wǎng)上的許多站點(diǎn)仍對(duì)此毫無防備亡问，以至于安全業(yè)界稱CSRF為“沉睡的巨人”官紫。
四.CSRF的原理
要完成一次CSRF攻擊，受害者必須依次完成兩個(gè)步驟：
1.登錄受信任網(wǎng)站A州藕，并在本地生成Cookie束世。
2.在不登出A的情況下，訪問危險(xiǎn)網(wǎng)站B床玻。
看到這里毁涉，你也許會(huì)說：“如果我不滿足以上兩個(gè)條件中的一個(gè)，我就不會(huì)受到CSRF的攻擊”笨枯。是的薪丁，確實(shí)如此，但你不能保證以下情況不會(huì)發(fā)生：
1.你不能保證你登錄了一個(gè)網(wǎng)站后馅精，不再打開一個(gè)tab頁面并訪問另外的網(wǎng)站。
2.你不能保證你關(guān)閉瀏覽器了后粱檀，你本地的Cookie立刻過期洲敢，你上次的會(huì)話已經(jīng)結(jié)束。（事實(shí)上茄蚯，關(guān)閉瀏覽器不能結(jié)束一個(gè)會(huì)話压彭，但大多數(shù)人都會(huì)錯(cuò)誤的認(rèn)為關(guān)閉瀏覽器就等于退出登錄/結(jié)束會(huì)話了......）
示例1：
銀行網(wǎng)站A，它以GET請(qǐng)求來完成銀行轉(zhuǎn)賬的操作渗常，如：http://www.mybank.com/Transfer.php?toBankId=11&money=1000
危險(xiǎn)網(wǎng)站B壮不，它里面有一段HTML的代碼如下：
?????? img?src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000
首先，你登錄了銀行網(wǎng)站A皱碘，然后訪問危險(xiǎn)網(wǎng)站B询一，噢，這時(shí)你會(huì)發(fā)現(xiàn)你的銀行賬戶少了1000塊......
示例2：
為了杜絕上面的問題癌椿，銀行決定改用POST請(qǐng)求完成轉(zhuǎn)賬操作健蕊。
銀行網(wǎng)站A的WEB表單如下：
form action="Transfer.php" method="POST"
ToBankId: input type="text" name="toBankId"
Money: input type="text" name="money"
input type="submit" value="Transfer"
form
后臺(tái)處理頁面Transfer.php如下：
<?
session_start();
if?(isset($_REQUEST['toBankId']?&& isset($_REQUEST['money']))
{
buy_stocks(
$_REQUEST['toBankId'], $_REQUEST['money']);
}
?>
危險(xiǎn)網(wǎng)站B，仍然只是包含那句HTML代碼：
?????? img?src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000
和示例1中的操作一樣踢俄，你首先登錄了銀行網(wǎng)站A缩功，然后訪問危險(xiǎn)網(wǎng)站B，結(jié)果.....和示例1一樣都办，你再次沒了1000塊～T_T嫡锌，這次事故的原因是：銀行后臺(tái)使用了$_REQUEST去獲取請(qǐng)求的數(shù)據(jù)虑稼，而$_REQUEST既可以獲取GET請(qǐng)求的數(shù)據(jù)，也可以獲取POST請(qǐng)求的數(shù)據(jù)势木，這就造成了在后臺(tái)處理程序無法區(qū)分這到底是GET請(qǐng)求的數(shù)據(jù)還是POST請(qǐng)求的數(shù)據(jù)蛛倦。在PHP中，可以使用$_GET和$_POST分別獲取GET請(qǐng)求和POST請(qǐng)求的數(shù)據(jù)跟压。在JAVA中胰蝠，用于獲取請(qǐng)求數(shù)據(jù)request一樣存在不能區(qū)分GET請(qǐng)求數(shù)據(jù)和POST數(shù)據(jù)的問題。
示例3：
經(jīng)過前面2個(gè)慘痛的教訓(xùn)震蒋，銀行決定把獲取請(qǐng)求數(shù)據(jù)的方法也改了茸塞，改用$_POST，只獲取POST請(qǐng)求的數(shù)據(jù)查剖，后臺(tái)處理頁面Transfer.php代碼如下：
<?
session_start();
if?(isset($_POST['toBankId']?&& isset($_POST['money']))
{
buy_stocks(
$_POST['toBankId'], $_POST['money']);
}
?>
然而钾虐，危險(xiǎn)網(wǎng)站B與時(shí)俱進(jìn)，它改了一下代碼：
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
如果用戶仍是繼續(xù)上面的操作笋庄，很不幸效扫，結(jié)果將會(huì)是再次不見1000塊......因?yàn)檫@里危險(xiǎn)網(wǎng)站B暗地里發(fā)送了POST請(qǐng)求到銀行!
理解上面的3種攻擊模式，其實(shí)可以看出直砂，CSRF攻擊是源于WEB的隱式身份驗(yàn)證機(jī)制菌仁！WEB的身份驗(yàn)證機(jī)制雖然可以保證一個(gè)請(qǐng)求是來自于某個(gè)用戶的瀏覽器，但卻無法保證該請(qǐng)求是用戶批準(zhǔn)發(fā)送的静暂！
五.CSRF的防御
CSRF的防御可以從服務(wù)端和客戶端兩方面著手济丘，防御效果是從服務(wù)端著手效果比較好，現(xiàn)在一般的CSRF防御也都在服務(wù)端進(jìn)行洽蛀。
1.服務(wù)端進(jìn)行CSRF防御
服務(wù)端的CSRF方式方法很多樣摹迷，但總的思想都是一致的，就是在客戶端頁面增加偽隨機(jī)數(shù)郊供。
(1).Cookie Hashing(所有表單都包含同一個(gè)偽隨機(jī)值)：
這可能是最簡(jiǎn)單的解決方案了峡碉，因?yàn)楣粽卟荒塬@得第三方的Cookie(理論上)，所以表單中的數(shù)據(jù)也就構(gòu)造失敗了
<?php
????????????? //構(gòu)造加密的Cookie信息
????????????? $value?=“DefenseSCRF”;
setcookie(”cookie”,?$value,?time()+3600);
?????????????? ?>
在表單里增加Hash值驮审，以認(rèn)證這確實(shí)是用戶發(fā)送的請(qǐng)求鲫寄。
<?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
然后在服務(wù)器端進(jìn)行Hash值驗(yàn)證
if(isset($_POST['check']))?{
??? $hash?=?md5($_COOKIE['cookie']);??????????
??? if($_POST['check']?==?$hash)?{
??????? doJob();
??? }
??? else{
??????? //...
??? }
}
else{
??? //...
}
這個(gè)方法個(gè)人覺得已經(jīng)可以杜絕99%的CSRF攻擊了，那還有1%呢....由于用戶的Cookie很容易由于網(wǎng)站的XSS漏洞而被盜取头岔，這就另外的1%塔拳。一般的攻擊者看到有需要算Hash值，基本都會(huì)放棄了峡竣，某些除外靠抑，所以如果需要100%的杜絕，這個(gè)不是最好的方法适掰。
(2).驗(yàn)證碼
這個(gè)方案的思路是：每次的用戶提交都需要用戶在表單中填寫一個(gè)圖片上的隨機(jī)字符串颂碧，這個(gè)方案可以完全解決CSRF荠列，但個(gè)人覺得在易用性方面似乎不是太好，還有聽聞是驗(yàn)證碼圖片的使用涉及了一個(gè)被稱為MHTML的Bug载城，可能在某些版本的微軟IE中受影響肌似。
(3).One-Time Tokens(不同的表單包含一個(gè)不同的偽隨機(jī)值)
在實(shí)現(xiàn)One-Time
Tokens時(shí)，需要注意一點(diǎn)：就是“并行會(huì)話的兼容”诉瓦。如果用戶在一個(gè)站點(diǎn)上同時(shí)打開了兩個(gè)不同的表單川队，CSRF保護(hù)措施不應(yīng)該影響到他對(duì)任何表單的提交〔窃瑁考慮一下如果每次表單被裝入時(shí)站點(diǎn)生成一個(gè)偽隨機(jī)值來覆蓋以前的偽隨機(jī)值將會(huì)發(fā)生什么情況：用戶只能成功地提交他最后打開的表單固额，因?yàn)樗衅渌谋韱味己蟹欠ǖ膫坞S機(jī)值。必須小心操作以確保CSRF保護(hù)措施不會(huì)影響選項(xiàng)卡式的瀏覽或者利用多個(gè)瀏覽器窗口瀏覽一個(gè)站點(diǎn)煞聪。
1).先是令牌生成函數(shù)(gen_token())：
<?php
??????????$token?= md5(uniqid(rand(),?true));return?$token;
}
2).然后是Session令牌生成函數(shù)(gen_stoken())：
<?php
functiongen_stoken()?{
?????? $pToken = "";
if($_SESSION[STOKEN_NAME]? == $pToken){
???????? //沒有值斗躏，賦新值
? $_SESSION[STOKEN_NAME]?= gen_token();
?????? }
????? else{
?? ? ? ? ? //繼續(xù)使用舊的值
????? }
}
?>
3).WEB表單生成隱藏輸入域的函數(shù)：
<?php
function gen_input() {
??? gen_stoken();
??? echo “value=\”" . $_SESSION[STOKEN_NAME] . “\”> “;
}
?>
4).WEB表單結(jié)構(gòu)：
<?php
??? session_start();
??? include(”functions.php”);
?>
form method=”POST” action=”transfer.php”
? ? ? ? ? input type=”text” name=”toBankId”
? ? ? ? ? input type=”text” name=”money”
? ? ? ? ? input type=”submit” name=”submit” value=”Submit”
? ? form
5).服務(wù)端核對(duì)令牌
轉(zhuǎn)載：[hyddd(http://www.cnblogs.com/hyddd/)]
