淺談CSRF的攻擊與防護

隨着互聯網的高速發展，web安全問題顯得愈發重要。

什麼是CSRF

CSRF全名是Cross Site Request Forgery，翻譯過來，即跨站請求僞造。那它是如何僞造的呢？請看下面的案例：

假如用戶 登陸了a網站 http://www.a.com，網站有一個get請求 xxx/delete?id=1 用於刪除用戶我的信息。 這時候彈出一個引人入勝的廣告被用戶點擊，或者用戶忽然有更重要的訪問其餘網站的需求而直接開了一個tab，暫停了a網站的訪問。

以上等緣由用戶來到了b網站（也多是釣魚網站） http://www.b.com。 b網站內已經藏好了一張不可見的圖片 <img src="xxx/delete?id=1" />； 等用戶返回a網站時，發現本身的我的信息不見了！

沒錯，就是這個看不見的圖片，發送了刪除我的信息的請求到a服務器，而a服務器又缺乏相應的防護措施，引發了災難。相似的場景也多是用戶的財產損失、帳號註銷……等等，假若該連接經過消息或發帖接口發送給好友或公共平臺，好友或平臺用戶查看到後，攻擊就會像病毒同樣散播開來（參照百度曾經的CSRF Worm）。

怎麼發起CSRF攻擊

這裏並非教你們怎麼搞壞事，咱們知道，知己知彼，方能百戰不殆。要知道怎麼防護，總得知道攻擊的特色纔好下手不是？

咱們知道http是無狀態的，即不會區分哪一個用戶、哪一個請求，不會記錄請求狀態。因此纔會有session、cookie用以區分用戶和校驗身份。這一步經過了，請求就認爲是合法的了。因此說咱們只要拿到了這個身份憑證（session、cookie），豈不是就能夠冒充用戶隨心所欲了？

那麼在用戶登陸了a網站 http://www.a.com後，又跳到（或打開）了b網站http://www.b.com。咱們在b網站裏有這樣的一個標籤

<img hidden src="http://www.a.com/xxx/delete?id=1" />
複製代碼

這個標籤一經加載，a網站的服務器就收到了這個刪除請求。 只能用img標籤攻擊嗎？ Too young, too simple. 具備src屬性的標籤均可以的。 那有人說把請求 /xxx/delete?id=1 方式改成post就好了吧？ Too young, too simple, too！ post請求咱們能夠這樣攻擊：

<form hidden action="http://www.a.com/xxx/delete" method="post">
    <input value="1" name="id" />
    // 假如還須要其餘參數，這裏再搞幾個表單出來
</form>
<script>
window.onload = function(){
    document.forms[0].submit();
}
</script>
複製代碼

怎麼防護CSRF攻擊

根據上面的攻擊過程，咱們發現只要僞造了session或cookie，後面每一步都挺順利的。防護的話，就是要它不那麼順利。

• 驗證碼

  這是最簡潔有效的方式，登陸、註冊、防止機器刷票咱們見多了。只惋惜咱們不能每一步每一個請求都這麼幹。

• Referer Check(至於爲啥Referer 不是寫做Referrer，那是歷史緣由，將錯就錯吧)

  若是一個請求來自域www.a.com，那麼服務器驗證客戶端的請求來源時，HTTP請求頭的Referer字段值就是www.a.com。這一步須要服務端來實現。問題在於，服務器不是何時都能取到Referer，甚至一些狀況下是不發送Referer的（緣由可自行查閱）。

• Anti CSRF Token

  CSRF 的本質是全部被僞造攻擊的請求的參數都是可被猜想到的。那咱們在請求參數里加上隨機生成的token，攻擊成本將瞬間擴大。token必須知足不可預測，假如咱們隨機產生的token是一個8位數字，那攻擊者暴力破解是分分鐘的事。token必須同時知足保密性和隨機性。

參考資料 《白帽子講Web安全》，吳翰清·著