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

问题描述

我读到在使用 JWT 时，不需要防范 CSRF 攻击，例如:"因为你不依赖cookies，所以你不需要保护跨站请求".

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

但是，我不明白的事情:如果我将令牌存储在 localStorage 中(正如我被告知的那样 在同一网站的教程上)，什么可以防止攻击者通过阅读我的 localStorage 而不是我的 cookie?

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.

首先，就 JavaScript 访问而言，HTML5 存储和 cookie 的范围存在细微差别.

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

HTML5 存储是:

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

• 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 除非 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:

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

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.

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

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

• (+) Authn令牌不能被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.

• 您的身份验证令牌是否保护与金钱有关的任何事情?您可能需要 cookie httpOnly secure 选项.
• 实施 CSRF 保护所需的努力程度是否不值得其保护的资产?那么 HTML5 存储可能是正确的地方.

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