CSRF
上一篇博客說的是XSS跨站腳本攻擊，現在說的是另一種跨站攻擊，CSRF（Cross-Site Request Forgery),跨站請求僞造。
1、概述
正如其名，CSRF是僞造請求，就是冒充用戶在站內進行正常操作。我們知道，絕大多數網站是通過Cookie等方式辨別用戶身份（包括使用服務器端Session的網站，因爲Session ID也是保存在Cookie裏面），再予以授權。這就是爲什麼要保護好用戶的Cookie。所以要想要僞造用戶的正常操作，就是要偷Cookie了，那麼可能就和上一篇裏面說過的XSS優點關聯了，利用XSS攻擊獲取被攻擊者的Cookie，在或者就是使用鏈接欺騙等途徑，讓用戶在本機發起用戶所不知道的請求，這裏說的本機是擁有Cookie的瀏覽器端。
2008年時由多個國內外大型社區和交互網站爆出CSRF漏洞，也是讓大家聚焦這個漏洞。其實這種攻擊方式在2000年就已經被國外的安全人員提出，但是在國內，直到2006年纔開始被關注。
2、分類
CSRF漏洞的攻擊一般分爲站內和站外兩種類型。
CSRF站內類型的漏洞一般都是因爲程序員濫用 $_REQUEST類變量造成的，一些敏感數據本來應該使用POST請求傳參，但是因爲使用了 $_REQUEST等變量，程序也可以接受GET類型請求傳參，這樣無形之中就給攻擊者提供了使用CSRF的條件，一般攻擊者只要把預測好的請求參數放入站內的一個帖子或者留言的圖片鏈接裏，受害者瀏覽了這樣的頁面就會被強制發起請求。
CSRF站外類型的漏洞其實就是外部數據提交問題，一般程序員會考慮給一些留言評論等的表單加上水印防止SPAM問題，但是爲了用戶的體驗性，一些操作可能沒有做任何限制，這是很危險的做法，因此攻擊者可以向預測好請求的參數，在站外的Web頁面裏編寫JavaScript腳本僞造文件請求或和自動提交的表單來實現GET、POST請求，用戶在會話狀態下單擊鏈接訪問站外的Web頁面，客戶端就被強迫發起請求。
3、原理
CSRF的原理如圖
這就相當於受害者需要在登錄A網站之後，再去訪問B網站，而B網站一般就是一些釣魚或者詐騙網站了。
4、攻擊場景
這裏舉一個例子說明：
假設有一個銀行A，它允許使用GET方式請求來轉賬操作，當然這就是個例子而已，現實生活中的銀行當然不可能只用GET請求轉賬。大家就看看就好，別想太多。
操作：http://www.Abank.com/Transfer.php?tobankID=13&money=1000
這個時候危險的網站B的代碼段中存在這樣的一句代碼：<img scr=" http://www.Abank.com/Tranfer.php?tobankID=13&money=1000" />
r.php?tobankID=13&money=1000" />`
那麼當返回A銀行時，就會發現賬戶上已經少了1000元。