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