幾乎所有關於反CSRF機制的文檔都聲明應該在服務器端生成CSRF令牌。不過，我想知道是否有必要。是否需要在服務器端生成反XSRF/CSRF令牌？
我想要實現反CSRF在下列步驟操作：
沒有服務器端生成的CSRF令牌;
在瀏覽器端，在每個AJAX或表單提交中，我們的JavaScript會生成一個隨機字符串作爲標記。在實際的AJAX或表單提交發生之前，該令牌被寫入cookie csrf;並將令牌添加到參數_csrf。
在服務器端，每個請求都應該有餅乾CSRF，並提交論證_csrf。這兩個值進行比較。如果它們不同，則意味着它是CSRF攻擊。
服務器端並不需要發出CSRF令牌，只是做了檢查;並且令牌在瀏覽器端完全生成。當然，這只是針對反CSRF。在服務器端應該有認證過程來驗證用戶ID。
這聽起來是CSRF的有效解決方案，但我不確定爲什麼沒有關於此方法的文檔。
這個反CSRF機制有什麼錯嗎？
據我所知，你想要做的是在客戶端創建你的反CSRF，將它存儲在一個cookie中，並將它作爲請求參數添加，所以當服務器讀取你的請求時，只需要驗證您的CSRF令牌cookie和參數是否匹配，並確定它是否是有效的請求。
在服務器端生成反僞造令牌的原因是，服務器將創建該令牌，並且只有服務器才知道正確的值，所以如果該參數在客戶端有輕微的篡改，它會與存儲在服務器中的不一樣，並且足以將該請求標記爲跨站點請求僞造攻擊。 任何客戶端生成的數據都可能被攻擊者篡改，因此，您不能依賴該信息，例如，在您的方法中，您在客戶端創建一個隨機值，並將該值分配給您的CSRF cookie和您的_csrf參數，假設您的值爲「h246drvhd4t2cd98」，但由於您只驗證客戶端的2個變量具有相同的值，因此攻擊者可以輕鬆創建CSRF Cookie和變量像他們和你的服務器上的「I'mByPassingThis」這樣的值會將其標記爲有效請求，所以你根本沒有獲得安全性。另一方面，如果在服務器中生成令牌，攻擊者無法知道期望值，並且每個請求的值都不相同，所以攻擊者的最佳方法就是試圖猜測它，這實際上是不可能的，除非你在服務器端使用可預測的隨機數生成器。另外，如果你想創建自己的反僞造令牌機制，你需要考慮使用一個密碼安全的僞隨機數發生器，但老實說，你不應該打擾，因爲當前的服務器 - 生成過程就是你所需要的（假設你的框架有一個內置的機制，如果沒有的話，那麼你仍然需要確保你使用了一個密碼安全的僞隨機數生成器來生成你的防僞標記）。
切記不要信任用戶提交的信息。由於它總是可以被篡改，因此您總是需要在服務器端執行一次雙重檢查，在這種情況下，在服務器中生成您的防僞標記可以讓您仔細檢查以驗證提交了反僞造令牌。