爲什麼我應該將CSRF令牌放入JWT令牌中？

Question

我想對Stormpath post中的JWT令牌和CSRF提出疑問，解釋將JWT存儲在localStorage或cookie中的優缺點。

[...]如果你正在讀出JS使用一個Cookie，這意味着你 不能設置中HTTPOnly標誌上的Cookie值，所以現在在您的網站 任何JS可以讀取它，從而使其與在localStorage中存儲 東西的安全級別完全相同。

我想了解爲什麼他們建議將xsrfToken添加到 智威湯遜。不會將JWT存儲在cookie中，然後將其提取並將JWT放入HTTP標頭中，並基於HTTP標頭對 請求進行身份驗證，完成與 Angular的X-XSRF-TOKEN相同的功能？如果您根據標頭 中的JWT進行身份驗證，則其他域名無需代表用戶發出請求 ，因爲其他域無法從cookie中提取JWT。我沒有 瞭解JWT中xsrfToken的用途 - 也許它只是 一個額外的防禦層 - 這意味着攻擊者必須在您的站點和CSRF當時有一個受損腳本。所以他們不得不用兩種方法打你，以便能夠進行攻擊。

的職位是在this answer掛在那裏說：

的最後一件事是要確保你有每 HTTP請求的CSRF保護，確保外部域發起請求到 你的網站不能功能。然後，在對服務器的每次請求中，確保您自己的 JavaScript代碼讀取cookie值，並將其設置爲自定義 標題，例如， X-CSRF-Token並在服務器上驗證 中的每個請求的值。 除非外部客戶端通過HTTP選項請求獲得授權 ，否則外部域客戶端無法爲您的域設置 請求的自定義標頭，因此任何嘗試進行CSRF攻擊（例如在 IFrame中，無論如何）都會失敗。

即使他們可以設置自定義標頭，他們也無法訪問存儲JWT令牌的cookie，因爲只有在同一個域上運行的JavaScript才能讀取該cookie。

他們可能通過XSS的唯一方式是在JWT中有一個xsrfToken，如果存在XSS漏洞也會受到威脅，因爲在可信客戶端域中運行的惡意腳本可以訪問cookie中的JWT，請求與xsrfToken。

所以公式應爲：

• TLS + JWT存儲在請求頭+無XSS漏洞的安全cookie +智威湯遜。

如果客戶端和服務器在不同的域中運行，服務器應該發送JWT，客戶端應該使用JWT創建cookie。 我認爲該方程對這種情況仍然有效。

UPDATE：MvdD agree with me：

由於瀏覽器不會自動將頭添加到您的要求， 它不容易受到CSRF攻擊

Answer 1

我的作者Stormpath博客文章。在JWT中存儲XSRF令牌並不是說它在JWT中，而是關於它在Cookie中。該cookie應該是httpOnly，所以你不能從Javascript讀取它。

現在，我認爲引起一點混亂的一點是我談論角度的問題。 Angular設置它只有XSRF cookie（不是httpOnly）才能在請求時將其放入標頭（只能通過同一個域中的javascript完成）。這些不是同一個cookie。

如果您考慮在您的應用程序中實現XSRF支持，這已經通過存儲服務器端狀態和存儲XSRF的要點完成。將它存儲在httpOnly cookie中與XSRF無關。在這裏，您將驗證JWT簽名，從聲明中獲取XSRF，並將其與頭部進行比較。

你的問題的答案是，你不需要在你的服務器上存儲狀態。

Answer 2

我的理解是這樣的：

• 商店智威湯遜是的HttpOnly的cookie。
• 在該JWT中，存儲散列版本的XSRF令牌。
• 客戶端發送的，當他們登錄，以便他們可以將其存儲在本地存儲
• 後來當客戶端發送請求，智威湯遜會自動通過cookie每個請求發送的XSRF令牌，然後你也可以通過發送XSRF令牌頁眉或查詢變量和服務器端，再哈希比較什麼是在智威湯遜在服務器上

你JWT被保護的XSS被竊取和你免受XSRF。 XSS仍然可以在瀏覽器上執行，但只能對瀏覽器中的會話造成損害。最終，您無法阻止某人編寫一個僅在您的瀏覽器上運行的非常詳細的腳本，因此Web開發人員仍然需要傳統的安全措施來保護XSS。