使用JSON Web令牌的CSRF保护 [英] CSRF protection with JSON Web Tokens

问题描述

我了解到，使用JWT时，无需防御CRSF攻击，例如:"

I read that when using JWT, there is no need to protect against CRSF attacks, for instance: "since you are not relying on cookies, you don't need to protect against cross site requests".

但是，我不明白的一些事情:如果我将令牌存储在localStorage中(根据建议

However, something I do not understand: if I store the token in localStorage (as I was advised on a tutorial of the same website), what prevents an attacker to forge a malicious request by reading my localStorage instead of my cookies ?

由于它是在服务器端生成的，因此我不知道如何在不将其存储在客户端某处的情况下将令牌用于客户端请求.

Since it was generated on the server side, I don't get how I could use a token for a client request without it being stored somewhere on the client.

推荐答案

严格来说，是的，存储在本地/会话存储(我称为HTML5存储)中的任何内容都可能在跨站点脚本(XSS)中被盗攻击.参见本文.

Strictly speaking, yes, anything stored in local/session storage (which I'll call HTML5 Storage) could be stolen in a cross-site scripting (XSS) attack. See this article.

但是，有很多运动部件需要考虑.

There are a lot of moving parts to consider, however.

首先，在HTML5存储和cookie的JavaScript访问范围方面存在细微的差异.

First, there are subtle differences in how HTML5 Storage and cookies are scoped with respect to JavaScript access.

HTML5存储为:

• 分为http和https.在https://example.com上运行的JavaScript无法访问http://example.com HTML5存储中存储的项目.
• 在子域之间划分.在http://sub.example.com上运行的JavaScript无法访问存储在http://example.com HTML5存储中的项目(您可以执行一些技巧来解决这个问题).

• divided between http and https. An item stored in http://example.com HTML5 storage cannot be accessed by JavaScript running on https://example.com.
• divided between subdomains. An item stored in http://example.com HTML5 storage cannot be accessed by JavaScript running on http://sub.example.com (you can do some tricks to get around this, however).

Cookie更加松散:

Cookies are more loosey-goosey:

• 具有域example.com的cookie将同时进入http://example.com和https://example.com ，除非它具有属性secure，在这种情况下，它将仅发送到https
• 未通过显式域发送的Cookie将仅发送回发送它的确切域.如果将域明确定义为example.com，则它将同时发送到example.com和sub.example.com. (很遗憾，这是Cookie规范"中最令人困惑的部分，请参见本文).
• 如果Cookie在具有匹配域(并遵守secure cookie标志)的页面上运行，则JavaScript可以读取它除非，该cookie具有httpOnly属性，其中如果JavaScript无法读取它.

• A cookie with a domain example.com will go to both http://example.com and https://example.com unless it has the attribute secure, in which case it will only be sent to https.
• A cookie not sent with an explicit domain will only be sent back to the exact domain that sent it. If the domain is explicitly defined to be example.com, then it will be sent to both example.com and sub.example.com. (This is the most confusing part of the cookie "spec", unfortunately, see this article).
• A cookie can be read by JavaScript if it is running on a page with a matching domain (and respecting the secure cookie flag) unless the cookie has the httpOnly attribute, in which case JavaScript will not be able to read it.

第二，由于cookie标记有域，因此，当向服务器发出请求时，浏览器将发送具有匹配域的所有cookie，而与的来源页面无关.请求.

Second, since cookies are marked with a domain, when a request is made to a server, the browser will send all-and-only cookies with a matching domain, regardless of the domain of the page that originated the request.

最后一部分是CSRF攻击是如何完成的(同源策略只能起到很大作用). CSRF上的OWASP页面是学习这些类型的好资源攻击有效.

The last part is how a CSRF attack is accomplished (the same-origin policy only helps so much). The OWASP page on CSRF is a good resource for learning how these kinds of attacks work.

将身份验证令牌存储在本地存储中并手动将其添加到每个请求中的原因在于，CSRF可以避免使用关键词:手动.由于浏览器不会自动发送该身份验证令牌，因此，如果我访问evil.com并且设法发送了POST http://example.com/delete-my-account，它将无法发送我的身份验证令牌，因此该请求将被忽略.

The reason storing an authentication token in local storage and manually adding it to each request protects against CSRF is that key word: manual. Since the browser is not automatically sending that auth token, if I visit evil.com and it manages to send a POST http://example.com/delete-my-account, it will not be able to send my authn token, so the request is ignored.

考虑到以上几点，是使用cookie还是HTML5存储成为一系列的权衡:

With the above in mind, whether to use a cookie or HTML5 Storage becomes a series of tradeoffs:

将authen令牌存储在HTML5存储中意味着:

Storing the authen token in HTML5 Storage means:

• (-)在XSS攻击中被盗的风险.
• (+)提供CSRF保护.
• (-)必须手动修改发送到服务器的每个请求，将您限制为SPA(例如AngularJs)Web应用程序.

• (-) Risk of it getting stolen in an XSS attack.
• (+) Provides CSRF protection.
• (-) Must manually modify each request going to the server, limiting you to SPA (eg AngularJs) web applications.

另一方面，如果将authn令牌存储在标记为httpOnly 和 secure的cookie中，则:

On the other hand, if you store the authn token in a cookie marked httpOnly and secure, then:

• (+)验证令牌不能被XSS窃取.
• (-)您将必须自行提供CSRF保护.在某些框架中，实施CSRF保护要比在其他框架中容易.

• (+) The authn token cannot be stolen by XSS.
• (-) You will have to provide CSRF protection yourself. Implementing CSRF protection is easier in some frameworks than others.

哪个选项更好取决于您的需求.

Which option is better depends on your needs.

• 您的authn令牌保护与金钱有关的任何事情吗?您可能需要cookie httpOnly secure选项.
• 实施CSRF保护所需的工作水平是否不值得其保护的资产?那么HTML5存储可能是正确的地方.

• Does your authn token protect anything to do with money? You'll probably want the cookie httpOnly secure option.
• Is the level of effort required to implement CSRF protection not worth the assets it's protecting? Then the HTML5 storage might be the right place.

这篇关于使用JSON Web令牌的CSRF保护的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！