問題描述

我想對 Stormpath 帖子，解釋將 JWT 存儲在 localStorage 或 cookie 中的優缺點.

I want to bring a doubt about JWT tokens and CSRF from the Stormpath post that explain the advantages and disadvantages of storing the JWT either in localStorage or cookies.

[...] 如果您使用 JS 從 cookie 中讀取值，這意味著您無法在 cookie 上設置 Httponly 標志，所以現在您網站上的任何 JS可以讀取它，從而使其具有與存儲完全相同的安全級別localStorage 中的一些東西.

[...] if you are reading values out of a cookie using JS, that means you can't set the Httponly flag on the cookie, so now any JS on your site can read it, thus making it the exact same security-level as storing something in localStorage.

我試圖了解他們為什么建議將 xsrfToken 添加到智威湯遜.不將您的 JWT 存儲在 cookie 中然后將其提取并將 JWT 放在 HTTP 標頭中并驗證基于 HTTP 標頭的請求完成與Angular 的 X-XSRF-TOKEN?沒有其他域可以在如果您基于標頭中的 JWT 進行身份驗證，則代表用戶，因為其他域無法從 cookie 中提取 JWT.我不了解 JWT 中 xsrfToken 的用途——也許它只是額外的防御層——這意味著攻擊者必須您的網站上有一個受損的腳本，并且當時有一個用戶 CSRF.所以他們必須以兩種方式擊中你才能發動攻擊.

I'm trying to understand why they recommend adding the xsrfToken to the JWT. Doesn't storing your JWT in the cookie and then extracting it out and placing the JWT in the HTTP header and authenticating the request based on the HTTP header accomplish the same thing as Angular's X-XSRF-TOKEN? No other domain could make requests on a user's behalf if you authenticate based on the JWT in the header, since other domains cannot extract the JWT from the cookie. I don't understand the purpose of the xsrfToken in the JWT - perhaps its just an additional layer of defense - meaning that attackers would have to have a compromised script on your site and CSRF a user at the time. So they'd have to hit you in both ways to be able to pull of an attack.

帖子鏈接在這個答案中，其中說:

The post is linked in this answer where says:

最后一件事是確保您在每個節點上都有 CSRF 保護HTTP請求確保外部域發起請求您的網站無法運行.

The last thing is to ensure that you have CSRF protection on every HTTP request to ensure that external domains initiating requests to your site cannot function.

[...] 然后，在每個請求進入您的服務器時，確保您自己的JavaScript 代碼讀取 cookie 值并將其設置為自定義標題，例如X-CSRF-Token 并在每個請求中驗證該值服務器.外部域客戶端無法為除非外部客戶端獲得授權，否則向您的域發出請求通過 HTTP 選項請求，因此任何 CSRF 攻擊嘗試(例如一個 IFrame，無論如何)對他們來說會失敗.

[...] Then, on every request into your server, ensure that your own JavaScript code reads the cookie value and sets this in a custom header, e.g. X-CSRF-Token and verify that value on every request in the server. External domain clients cannot set custom headers for requests to your domain unless the external client gets authorization via an HTTP Options request, so any attempt at a CSRF attack (e.g. in an IFrame, whatever) will fail for them.

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

Even if they could set custom headers, they couldn't access the cookie where the JWT token is stored because only JavaScript that runs on the same domain can read the cookie.

他們唯一的方法是通過 XSS，但是如果存在 XSS 漏洞，JWT 中的 xsrfToken 也會受到損害，因為在受信任的客戶端域中運行的惡意腳本可以訪問 cookie 中的 JWT 并在請求中包含標頭使用 xsrfToken.

The only way they could is via XSS, but having an xsrfToken in the JWT is compromised too if exists XSS vulnerabilities because a malicious script running in the trusted client domain could access the JWT in the cookie and include a header in the request with the xsrfToken.

所以方程應該是:

• TLS + JWT 存儲在安全 cookie + 請求標頭中的 JWT + 無 XSS 漏洞.

如果客戶端和服務器在不同的域中運行，服務器應該發送 JWT，客戶端應該使用 JWT 創建 cookie.我認為這個等式在這種情況下仍然有效.

If the client and server are running in different domains, the server should send the JWT and the client should create the cookie with the JWT. I think that the equation is still valid for this situation.

更新: MvdD 同意我的看法:

由于瀏覽器不會自動將標頭添加到您的請求中，它不易受到 CSRF 攻擊

As the browser does not automatically add the header to your request, it is not vulnerable to a CSRF attack

推薦答案

我是 Stormpath 博客文章的作者.將 XSRF 令牌存儲在 JWT 中并不是關于它在 JWT 中，而是關于它在 cookie 中.cookie 應該是 httpOnly，所以你不能從 Javascript 中讀取它.

I am the author of the Stormpath Blog Post. Storing XSRF token in the JWT isn't about that it is in the JWT, it is about that it is in a cookie. The cookie should be httpOnly, so you can not read it from Javascript.

現在，我認為引起一點混亂的一點是我在談論角度.Angular 也將它設置為只有 XSRF cookie(不是 httpOnly)，以便在請求時將其放入標頭中(只能由同一域上的 javascript 完成).這些不是同一個cookie.

Now, I think the point that caused a little confusion is where I talk about angular. Angular sets it's only XSRF cookie as well (which is not httpOnly) to put it into the header at request time (which can only be done by javascript on same domain). These are not the same cookie.

如果您考慮在您的應用程序中實現 XSRF 支持，這已經通過存儲服務器端狀態和存儲 XSRF 的點來完成.將其存儲在 httpOnly cookie 中意味著使用 XSRF 實現無狀態.在這里，您將驗證 JWT 簽名，從聲明中獲取 XSRF，并將其與標頭進行比較.

If you think about implementing XSRF support in your application, this has been done with storing server side state and the point of storing the XSRF. Storing it in the httpOnly cookie is about being stateless with XSRF. Here, you would validate the JWT signature, get the XSRF out of the claims, and compare it to the header.

您的問題的答案是您不需要在服務器上存儲狀態.

The answer to your question is so that you do not need to store state on your server.

這篇關于為什么要將 CSRF 令牌放入 JWT 令牌中?的文章就介紹到這了，希望我們推薦的答案對大家有所幫助，也希望大家多多支持html5模板網！