我正在嘗試了解CSRF的整個問題以及適當的預防方法。（我已閱讀，理解并同意的資源：OWASP CSRF預防速查表，有關CSRF的問題。）據我了解，CSRF周圍的漏洞是由以下假設引入的：從Web服務器的角度來看，傳入HTTP請求中的有效會話cookie反映了經過身份驗證的用戶的意愿。但是，源域的所有cookie都被瀏覽器神奇地附加到了請求上，因此，實際上服務器可以從請求中存在有效會話cookie推斷出，該請求來自具有經過身份驗證的會話的瀏覽器。它無法進一步假設有關代碼的任何信息在該瀏覽器中運行，或者是否確實反映了用戶的意愿。防止這種情況的方法是在請求中包括其他身份驗證信息（“ CSRF令牌”），該信息由瀏覽器的自動cookie處理以外的其他方式攜帶。松散地說，會話cookie對用戶/瀏覽器進行身份驗證，而CSRF令牌對在瀏覽器中運行的代碼進行身份驗證。因此，簡而言之，如果您使用會話cookie來驗證Web應用程序的用戶，則還應該向每個響應中添加CSRF令牌，并在每個（變異）請求中要求匹配的CSRF令牌。然后，CSRF令牌從服務器到瀏覽器再返回到服務器，以向服務器證明發出請求的頁面已被該服務器批準（由該服務器生成，甚至由該服務器生成）。關于我的問題，這是關于該往返行程中用于該CSRF令牌的特定傳輸方法。似乎很常見（例如在AngularJS，Django，Rails中）將CSRF令牌作為cookie從服務器發送到客戶端（即在Set-Cookie標頭中），然后讓客戶端中的Javascript將其從cookie中刮出并附加它作為單獨的XSRF-TOKEN標頭發送回服務器。（另一種方法是Express推薦的方法，其中服務器生成的CSRF令牌通過服務器端模板擴展包含在響應主體中，并直接附加到將其提供回服務器的代碼/標記中，例如作為隱藏的表單輸入。該示例是一種更像Web 1.0的工作方式，但可以推廣到使用更多JS的客戶端。）為什么使用Set-Cookie作為CSRF令牌的下游傳輸如此普遍/為什么這是個好主意？我想所有這些框架的作者都仔細考慮了他們的選擇，并沒有弄錯這一點。但是乍看之下，使用cookie來解決cookie的本質設計限制似乎很愚蠢。實際上，如果您使用cookie作為往返傳輸（服務器的Set-Cookie：下游標頭告訴瀏覽器CSRF令牌，瀏覽器的cookie：上游標頭將瀏覽器返回給服務器），則會重新引入該漏洞正在嘗試修復。我意識到上述框架并未在CSRF令牌的整個往返過程中使用cookie；他們在下游使用Set-Cookie，然后在上游使用其他內容（例如X-CSRF-Token標頭），這確實消除了該漏洞。但是，即使使用Set-Cookie作為下游運輸工具，也可能會產生誤導和危險；瀏覽器現在將CSRF令牌附加到每個請求，包括真正的惡意XSRF請求；最好的情況是使請求大于所需的大小，最壞的情況是一些善意卻被誤導的服務器代碼實際上可能嘗試使用它，這確實很糟糕。而且，由于CSRF令牌的實際預期接收者是客戶端Javascript，這意味著該cookie不能僅通過http保護。