不同于Token和Refer頭校驗的另一種CSRF防御辦法

情的情況是這樣的，前段時間在工作中發現XX系統存在CSRF漏洞，我在數據包內并未看到對應的Token參數，測試Refer頭后發現XX系統并未對請求來源（refer）進行相關校驗。我便認為此處存在CSRF漏洞并將該漏洞發送給了XX系統的相關負責人。

但是過了幾天后XX系統的負責人發來一份反饋郵件，郵件說他們系統做了CSRF校驗但用的不是Token也不是Refer。而是如下方法：

XX系統使用X-Uni-Csrf-Token做referer標志頭校驗，X-Uni-Csrf-Tokenk是服務器自定義的一個HTTP請求行；X-Uni-Csrf-Token是用戶登錄之后，后端服務器根據用戶token等信息和用戶會話綁在一起，給前端一個隨機數，然后前端再次請求后端系統會帶上這個隨機數，后端驗證此參數來判斷是否為為同一域名下面的請求；X-Uni-Csrf-Token隨機數隨著用戶會話消失而消失，用戶下次登錄會生成新的會話和X-Uni-Csrf-Token隨機數；XX系統的會話時間默認是30分鐘，進而防止csrf跨站請求偽造攻擊。數據包如下：

與XX相關人員溝通后，我對于他們這個方法的解讀：

當用戶成功登陸系統后，服務器端根據用戶Session等信息經過一定的算法運算生成一個隨機數（即X-Uni-Csrf-Token），然后將此隨機數與用戶Session綁定起來發送給客戶端。客戶端將此隨機數存儲在用戶內存中，之后每次用戶通過點擊頁面功能點，由前端JS控制將此隨機數從用戶計算機內從中取出作為并HTTP請求行的一個參數發給服務器，服務器收到HTTP請求后會對該參數進行校驗，如果請求中包括該參數并且參數值與用戶綁定的值相同，則認為該請求來自用戶本人操作，該HTTP請求被執行。

簡述：此例中的X-Uni-Csrf-Token相當于研發自己造的一個refer頭，里面的參數為Token。服務器通過校驗該參數來判斷此HTTP請求是否來自用戶本人操作。

相關知識：默認情況下JS只會將用戶Cookie信息從內存或本地文件中調用并往服務器。

不足：頁面不能存在XSS漏洞導致JS代碼被執行。

由于我的見識短淺，我的理解可能有所偏差，請給位看官見諒。

版權申明：內容來源網絡，版權歸原創者所有。除非無法確認，都會標明作者及出處，如有侵權，煩請告知，我們會立即刪除并致歉!