淺談CSRF攻擊方式
轉(zhuǎn)自：http://www.cnblogs.com/hyddd/
一.CSRF是什么？
CSRF（Cross-site request forgery），中文名稱：跨站請(qǐng)求偽造，也被稱為：one click attack/session riding，縮寫(xiě)為：CSRF/XSRF。
二.CSRF可以做什么？
你這可以這么理解CSRF攻擊：攻擊者盜用了你的身份，以你的名義發(fā)送惡意請(qǐng)求。CSRF能夠做的事情包括：以你名義發(fā)送郵件，發(fā)消息，盜取你的賬號(hào)，甚至于購(gòu)買商品，虛擬貨幣轉(zhuǎn)賬......造成的問(wèn)題包括：個(gè)人隱私泄露以及財(cái)產(chǎn)安全。
三.CSRF漏洞現(xiàn)狀
CSRF這種攻擊方式在2000年已經(jīng)被國(guó)外的安全人員提出，但在國(guó)內(nèi)，直到06年才開(kāi)始被關(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ì)此毫無(wú)防備，以至于安全業(yè)界稱CSRF為“沉睡的巨人”。
四.CSRF的原理
下圖簡(jiǎn)單闡述了CSRF攻擊的思想：
從上圖可以看出，要完成一次CSRF攻擊，受害者必須依次完成兩個(gè)步驟：
1.登錄受信任網(wǎng)站A，并在本地生成Cookie。
2.在不登出A的情況下，訪問(wèn)危險(xiǎn)網(wǎng)站B。
看到這里，你也許會(huì)說(shuō)：“如果我不滿足以上兩個(gè)條件中的一個(gè)，我就不會(huì)受到CSRF的攻擊”。是的，確實(shí)如此，但你不能保證以下情況不會(huì)發(fā)生：
1.你不能保證你登錄了一個(gè)網(wǎng)站后，不再打開(kāi)一個(gè)tab頁(yè)面并訪問(wèn)另外的網(wǎng)站。
2.你不能保證你關(guān)閉瀏覽器了后，你本地的Cookie立刻過(guò)期，你上次的會(huì)話已經(jīng)結(jié)束。（事實(shí)上，關(guān)閉瀏覽器不能結(jié)束一個(gè)會(huì)話，但大多數(shù)人都會(huì)錯(cuò)誤的認(rèn)為關(guān)閉瀏覽器就等于退出登錄/結(jié)束會(huì)話了......）
3.上圖中所謂的攻擊網(wǎng)站，可能是一個(gè)存在其他漏洞的可信任的經(jīng)常被人訪問(wèn)的網(wǎng)站。
上面大概地講了一下CSRF攻擊的思想，下面我將用幾個(gè)例子詳細(xì)說(shuō)說(shuō)具體的CSRF攻擊，這里我以一個(gè)銀行轉(zhuǎn)賬的操作作為例子（僅僅是例子，真實(shí)的銀行網(wǎng)站沒(méi)這么傻:>）
示例1：
銀行網(wǎng)站A，它以GET請(qǐng)求來(lái)完成銀行轉(zhuǎn)賬的操作，如：http://www.mybank.com/Transfer.php?toBankId=11&money=1000
危險(xiǎn)網(wǎng)站B，它里面有一段HTML的代碼如下：
首先，你登錄了銀行網(wǎng)站A，然后訪問(wèn)危險(xiǎn)網(wǎng)站B，噢，這時(shí)你會(huì)發(fā)現(xiàn)你的銀行賬戶少了1000塊......
為什么會(huì)這樣呢？原因是銀行網(wǎng)站A違反了HTTP規(guī)范，使用GET請(qǐng)求更新資源。在訪問(wèn)危險(xiǎn)網(wǎng)站B的之前，你已經(jīng)登錄了銀行網(wǎng)站A，而B(niǎo)中 的以GET的方式請(qǐng)求第三方資源（這里的第三方就是指銀行網(wǎng)站了，原本這是一個(gè)合法的請(qǐng)求，但這里被不法分子利用了），所以你的瀏 覽器會(huì)帶上你的銀行網(wǎng)站A的Cookie發(fā)出Get請(qǐng)求，去獲取資源“http://www.mybank.com /Transfer.php?toBankId=11&money=1000”，結(jié)果銀行網(wǎng)站服務(wù)器收到請(qǐng)求后，認(rèn)為這是一個(gè)更新資源操作（轉(zhuǎn)賬 操作），所以就立刻進(jìn)行轉(zhuǎn)賬操作......
示例2：
為了杜絕上面的問(wèn)題，銀行決定改用POST請(qǐng)求完成轉(zhuǎn)賬操作。
銀行網(wǎng)站A的WEB表單如下：
ToBankId:?
Money:?
后臺(tái)處理頁(yè)面Transfer.php如下：
session_start();
if?(isset($_REQUEST['toBankId']?&& isset($_REQUEST['money']))
{
buy_stocks($_REQUEST['toBankId'], $_REQUEST['money']);
}
?>
危險(xiǎn)網(wǎng)站B，仍然只是包含那句HTML代碼：
和示例1中的操作一樣，你首先登錄了銀行網(wǎng)站A，然后訪問(wèn)危險(xiǎn)網(wǎng)站B，結(jié)果.....和示例1一樣，你再次沒(méi)了1000塊～T_T，這次事故的 原因是：銀行后臺(tái)使用了$_REQUEST去獲取請(qǐng)求的數(shù)據(jù)，而$_REQUEST既可以獲取GET請(qǐng)求的數(shù)據(jù)，也可以獲取POST請(qǐng)求的數(shù)據(jù)，這就造成 了在后臺(tái)處理程序無(wú)法區(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ù)的問(wèn)題。
示例3：
經(jīng)過(guò)前面2個(gè)慘痛的教訓(xùn)，銀行決定把獲取請(qǐng)求數(shù)據(jù)的方法也改了，改用$_POST，只獲取POST請(qǐng)求的數(shù)據(jù)，后臺(tái)處理頁(yè)面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)，它改了一下代碼：
function?steal()
{
iframe?=?document.frames["steal"];
iframe.document.Submit("transfer");
}