一個express老系統csrf漏洞修復

一個運行快兩年的express框架web系統，被安所有門審覈存在csrf漏洞，項目使用的先後端分離的形式，全部功能操做，經過ajax調用後端接口來完成，查了不少資料，一個基本的防護思想就是驗證隨機數了，爲何隨機數就能夠實現csrf的防護呢？本文將針對該問題進行分解

什麼是csrf

csrf(跨站請求僞造)是一種網絡攻擊方式，怎麼實現這種攻擊方式呢？
1.登陸受信任網站A，並在本地生成Cookie
2.在不登出A的狀況下，訪問危險網站B，B站存在一個針對A站惡意的路由操做，如刪除某條記錄
用戶操做後，就會刪除形成對A站的攻擊
若是不知足以上兩個條件中的一個，就不會受到CSRF的攻擊

示例1：
　　銀行網站A，它以GET請求來完成銀行轉帳的操做，如：
http://www.mybank.com/Transfer.php?toBankId=11&money=1000
　　危險網站B，它裏面有一段HTML的代碼以下：
　　<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>
　　首先，你登陸了銀行網站A，而後訪問危險網站B，噢，這時你會發現你的銀行帳戶少了1000塊......
雖然存在着巨大的不肯定性，可是這種漏洞危害性也是巨大的

csrf的防護策略

針對以上的攻擊方式，咱們要採起防護措施

• 驗證 HTTP Referer 字段

HTTP 協議，在 HTTP 頭中有一個字段叫 Referer，它記錄了該 HTTP 請求的來源地址。在一般狀況下，訪問一個安全受限頁面的請求來自於同一個網站，好比須要訪問 http://bank.example/withdraw?...，用戶必須先登錄 bank.example，而後經過點擊頁面上的按鈕來觸發轉帳事件。這時，該轉賬請求的 Referer 值就會是轉帳按鈕所在的頁面的 URL，一般是以 bank.example 域名開頭的地址。而若是黑客要對銀行網站實施 CSRF 攻擊，他只能在他本身的網站構造請求，當用戶經過黑客的網站發送請求到銀行時，該請求的 Referer 是指向黑客本身的網站。所以，要防護 CSRF 攻擊，銀行網站只須要對於每個轉帳請求驗證其 Referer 值，若是是以 bank.example 開頭的域名，則說明該請求是來自銀行網站本身的請求，是合法的。若是 Referer 是其餘網站的話，則有多是黑客的 CSRF 攻擊，拒絕該請求。
因爲Referer能夠篡改，因此這種方案安全性較低。

• 驗證碼的方式

每一次操做前添加驗證碼，該種方案較繁瑣，通常不會採用。

• 隨機數驗證

如今csrf防護主要採用該種方式，基本流程

1. 服務端產生一個隨機數，發送到客戶端
2. 客戶端在表單提交時，攜帶該隨機數
3. 在服務端驗證該隨機數

基本的防護思想就是這樣的流程，那麼怎麼來怎麼實現這樣的業務代碼。

因爲項目是一個老的系統，因此採起切面處理的方式，

1. 在服務端生成一個隨機數csrf,而後加密生成csrftoken，而後將這兩個值發送到客戶端
2. 在請求時將header中攜帶csrftoken
3. 服務端驗證加密後csrf和csrftoken是否相等

該種方案略顯複雜，精簡一下

1. 服務生成一個隨機數token，設置cookie
2. 在客戶端生成通過md5(token)生成一個csrftoken，在請求時攜帶在header中
3. 在服務端，取cookie中的token，通過md(token)算法後和header中的csrftoken作比較