常見的攻擊手段--CSRF

假設某銀行網站A，他以GET請求來發起轉帳操做，轉帳的地址爲www.xxx.com/transfer.do?
accountNum=10001&money=10000，accountNum參數表示轉帳的目的帳戶，money參數表
示轉帳金額。
而某大型論壇B上，一個惡意用戶上傳了一張圖片，而圖片的地址欄中填的並非圖片的地
址，而是前面所說的轉帳地址：
<img src= "http://www.xxx.com/transfer.do?accountNum=10001&money=10000" >
當你登錄網站A後，沒有及時登出，這個時候你訪問了論壇B，不幸的事情發生了，你會發
現你的帳戶裏面少了10000塊……
爲何會這樣呢，在你登錄銀行A的時候，你的瀏覽器端會生成銀行A的cookie，而當你訪
問論壇B的時候，頁面上的<img>標籤須要瀏覽器發起一個新的HTTP請求，以得到圖片資源，
當瀏覽器發起請求的時候，請求的倒是銀行A的轉帳地址www.xxx.com/transfer.do?accoun
tNum=10001&money=10000，而且會帶上銀行A的cookie信息，結果銀行的服務器收到這
個請求後，會認爲是你發起的一次轉帳操做，所以你的帳戶裏邊便少了10000塊。

常見的攻擊手段—CSRF的防護

1.cookie設置爲HttpOnly
CSRF攻擊很大程度上是利用了瀏覽器的cookie，爲了防止站內的XSS漏洞盜取cookie，須要
在cookie中設置"HttpOnly"屬性，這樣經過程序(如JavascriptS腳本、Applet等)就沒法讀
取到cookie信息，避免了攻擊者僞造cookie的狀況出現。
2.增長token
CSRF攻擊之因此可以成功，是由於攻擊者能夠僞造用戶的請求，該請求中全部的用戶驗證
信息都存在於cookie中，所以攻擊者能夠在不知道用戶驗證信息的狀況下直接利用用戶的
cookie來經過安全驗證。由此可知，抵禦CSRF攻擊的關鍵在於：在請求中放入攻擊者所不
能僞造的信息，而且該信息不存在於cookie之中。鑑於此，系統開發人員能夠在HTTP請求
中以參數的形式加入一個隨機產生的token，並在服務端進行token校驗，若是請求中沒有
token或者token內容不正確，則認爲是CSRF攻擊而拒絕該請求。

3.經過Referer識別
根據HTTP協議，在HTTP頭中有一個字段叫Referer，它記錄了該HTTP請求的來源地址。在一般
狀況下，訪問一個安全受限頁面的請求都來自於同一個網站。好比某銀行的轉帳是經過用戶訪
問http://www.xxx.com/transfer.do頁面完成，用戶必須先登陸www.xxx.com，而後經過點擊
頁面上的提交按鈕來觸發轉帳事件。當用戶提交請求時，該轉帳請求的Referer值就會是提交
按鈕所在頁面的URL（本例爲www.xxx.com/transfer.do）。若是攻擊者要對銀行網站實施CSRF
攻擊，他只能在其餘的網站構造請求，當用戶經過其餘網站發送請求到銀行時，該請求的
Referer的值是其餘網站的地址，而不是銀行轉帳頁面的地址。
所以，要防護CSRF攻擊，銀行網站只須要對於每個轉帳請求驗證其Referer值，若是是以
www.xxx.com域名開頭的地址，則說明該請求是來自銀行網站本身的請求，是合法的。若是
Referer是其餘網站的話，就有多是CSRF攻擊，則拒絕該請求。