sessionStorage和cookie中的JWT令牌？ [英] JWT tokens in sessionStorage vs cookies?

问题描述

有很多从Stormpath的博客文章，谈论你应该如何使用cookies来存储您的JWT，而不是sessionStorage / localStorage：

There are a lot of blog posts from Stormpath that talk about how you ought to use cookies to store your JWT instead of sessionStorage/localStorage:

• https：// stormpath。 com / blog / where-to-store-your-jwts-cookies-vs-html5-web-storage


• https://stormpath.com/blog/token-auth-spa


• https://stormpath.com/blog/build-secure-user-interfaces-using-jwts

• https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage
• https://stormpath.com/blog/token-auth-spa
• https://stormpath.com/blog/build-secure-user-interfaces-using-jwts

主要的原因是，如果加载的第三方javascript依赖关系受到损害，它可以通过sessionStorage / localStorage，并将JWT传送到某个地方。

The main stated reason is that if a 3rd-party javascript dependency that you load is compromised that it can pilfer through sessionStorage/localStorage and transmit off the JWT to somewhere.

但这是令人困惑的一个原因。我明白攻击向量，但如果你有一个妥协的第三方JavaScript依赖，你没有有效地拧，反正，因为它可以监听/捕获任何你的用户做的，因为他们与你的应用程序交互？

But this is confusing as a reason to me. I understand the attack vector, but if you have a compromised 3rd-party javascript dependency, aren't you effectively screwed anyway, since it can listen-in/capture anything your users do as they interact with your app?

推荐答案

我是 https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage

当页面上存在XSS时，攻击者有权：

When XSS exist on a page, an attacker is privileged to:

• HTML5 Web存储和会话）


• 未使用httpOnly标记设置的Cookie


• 控制选项卡，直到其关闭并允许未经授权的请求
• 
  

• HTML5 web storage (local and session)
• Cookies that are not set with httpOnly flag
• Control of the tab until it is closed and the ability to make unauthorized requests

您也可以开始制定攻击以获得XSRF保护。

You can also start to formulate attacks to get around XSRF protection.

存在XSRF漏洞，攻击者有权：

When an XSRF vulnerability exists, an attacker is privileged to:

• 从第三方域提出未经授权的请求，或在XSS的存在下将它们发送到那里）。

您可以看到，当存在XSS漏洞时，您可以进行未经授权的请求，攻击者需要跳过更多环境来利用XSRF。这意味着当XSS存在时（不管是否有XSRF保护），存在未授权请求的攻击向量。

You can see that when an XSS vulnerability exists, you are able to make unauthorized requests and an attacker would need to jump through some more hoops to exploit XSRF. This means that when XSS exists (regardless of XSRF protection or not), the attack vector of making unauthorized requests will exist.

希望能清除我的下一个点。

Hopefully, that clears things up for my next point.

与窃取表示用户身份和会话的无状态令牌相比，XSRF攻击或未授权请求的影响和范围较小。泄露令牌意味着攻击者将完全控制代表用户，在他的时间，在他的机器上制定攻击。

An XSRF attacks or unauthorized requests has less impact and scope than stealing a stateless token that represents the user's identity and session. Leaking the token means that an attacker will have full control to formulate an attack on behalf of the user, on his time, on his machines.

总之，在存在XSS当您：

In conclusion, in presence of XSS when you:

• 在网络存储中存储访问令牌，任何使用您网站的用户的令牌XSS的存在被破坏。这意味着攻击者可能会获得成千上万的有效访问令牌，并可能造成很多伤害（如果您在网络存储中存储刷新令牌，则更多）。

• store an access token in web storage, the tokens for any user that uses your site during the time of the existence of XSS is compromised. This means an attacker could get thousands of valid access tokens and can possibly do a lot of harm (even more if you store refresh tokens in web storage). The users are also vulnerable to making unauthorized requests from their own browser.

在httpOnly Cookie中存储访问令牌，任何用户的令牌都不会被泄露。但是，即使在存在XSRF保护的情况下，用户也容易受到来自自己浏览器的未经授权的请求。

store an access token in a httpOnly cookie, the tokens for any user are not compromised. But, the users are also vulnerable to making unauthorized requests from their own browser even in the presence of XSRF protection.

希望此信息有帮助。

这篇关于sessionStorage和cookie中的JWT令牌？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！