一個運行快兩年的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防御主要采用該種方式，基本流程

服務端產生一個隨機數，發送到客戶端

客戶端在表單提交時，攜帶該隨機數

在服務端驗證該隨機數

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

由于項目是一個老的系統，所以采取切面處理的方式，

在服務端生成一個隨機數csrf,然后加密生成csrftoken，然后將這兩個值發送到客戶端

在請求時將header中攜帶csrftoken

服務端驗證加密后csrf和csrftoken是否相等

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

服務生成一個隨機數token，設置cookie

在客戶端生成經過md5(token)生成一個csrftoken，在請求時攜帶在header中

在服務端，取cookie中的token，經過md(token)算法后和header中的csrftoken做比較

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的一个express老系统csrf漏洞修复的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。