在浏览器中存储 JWT 的位置？如何防范 CSRF？

我们需要将 JWT 存储在客户端计算机上。如果我们将它存储在 LocalStorage/SessionStorage 中，那么它很容易被 XSS 攻击所抓取。如果我们将它存储在 cookie 中，那么黑客可以在 CSRF 攻击中使用它（无需读取它）并冒充用户并联系我们的 API 并发送请求以代表用户执行操作或获取信息。

但是有几种方法可以保护 cookie 中的 JWT 不被轻易窃取（但仍然有一些先进的技术可以窃取它们）。但是如果你想依赖 LocalStorage/SessionStorage，那么可以通过简单的 XSS 攻击来访问它。

所以为了解决 CSRF 问题，我在我的应用程序中使用了 Double Submit Cookies。

双重提交 Cookies 方法

将 JWT 存储在 HttpOnly cookie 中，并在安全模式下使用它通过 HTTPS 传输。大多数 CSRF 攻击在其请求中与您的原始主机具有不同的来源或引荐来源标头。因此，请检查标题中是否有任何它们，它们是否来自您的域！如果不拒绝他们。如果请求中的来源和推荐人都不可用，那么不用担心。您可以依赖我在下一步中解释的 X-XSRF-TOKEN 标头验证结果的结果。虽然浏览器会自动为请求的域提供 cookie，但有一个有用的限制：在网站上运行的 JavaScript 代码无法读取其他网站的 cookie。我们可以利用它来创建我们的 CSRF 解决方案。为了防止 CSRF 攻击，我们必须创建一个额外的 Javascript 可读 cookie，称为：XSRF-TOKEN。此 cookie 必须在用户登录时创建，并且应该包含一个随机的、不可猜测的字符串。我们还将这个数字作为私人声明保存在 JWT 中。每次 JavaScript 应用程序想要发出请求时，它都需要读取此令牌并将其发送到自定义 HTTP 标头中。因为这些操作（读取 cookie、设置标头）只能在 JavaScript 应用程序的同一个域上完成，所以我们可以知道这是由使用我们的 JavaScript 应用程序的真实用户完成的。

Angular JS 让你的生活变得轻松

幸运的是，我在我们的平台中使用了 Angular JS，并且 Angular 封装了 CSRF 令牌方法，使我们更容易实现。对于我们的 Angular 应用程序向服务器发出的每个请求，Angular $http 服务将自动执行以下操作：

在当前域中查找名为 XSRF-TOKEN 的 cookie。

如果找到该 cookie，它会读取该值并将其作为 X-XSRF-TOKEN 标头添加到请求中。

因此，客户端实现会自动为您处理！我们只需要在服务器端的当前域上设置一个名为 XSRF-TOKEN 的 cookie，当我们的 API 收到来自客户端的任何调用时，它必须检查 X-XSRF-TOKEN 标头并将其与 JWT 中的 XSRF-TOKEN 进行比较。如果它们匹配，则用户是真实的。否则，这是一个伪造的请求，您可以忽略它。此方法的灵感来自“双重提交 Cookie”方法。

警告

实际上，您仍然容易受到 XSS 的影响，只是攻击者无法窃取您的 JWT 令牌以供以后使用，但他仍然可以使用 XSS 代表您的用户发出请求。

无论您将 JWT 存储在 localStorage 中，还是将 XSRF 令牌存储在非 HttpOnly cookie 中，XSS 都可以轻松获取两者。甚至 HttpOnly cookie 中的 JWT 也可能被 XST method 等高级 XSS 攻击获取。

因此，除了双重提交 Cookie 方法之外，您还必须始终遵循针对 XSS 的最佳实践，包括转义内容。这意味着删除任何会导致浏览器执行您不希望它执行的操作的可执行代码。这通常意味着删除导致 JavaScript 被评估的 // <![CDATA[ 标记和 HTML 属性。

在这里阅读更多：

Angular 的 XSRF：它是如何工作的

JWT 的存储位置——Cookie 与 HTML5 Web 存储

---

JWT 令牌很受欢迎，因为它们在 OAuth 2.0 和 OpenID Connect 等新的授权和身份验证协议中用作默认令牌格式。

当令牌存储在 cookie 中时，浏览器会自动将其与每个请求一起发送到同一个域，这仍然容易受到 CSRF 攻击。

承载身份验证是 HTTP 中定义的 authentication schemes 之一。这基本上意味着 YOU 将 (JWT) 令牌粘贴在请求的 Authorization HTTP 标头中。浏览器不会自动为您执行此操作，因此它不适合保护您的网站。由于浏览器不会自动将标头添加到您的请求中，因此它不容易受到 CSRF 攻击，这取决于您的身份验证信息是否自动提交到原始域。

承载方案通常用于保护通过 AJAX 调用或移动客户端使用的 Web API（REST 服务）。

---

现在在 2020 年，只需将 JWT 令牌存储在带有 SameSite=strict 的 cookie 中即可击败 CSRF。当然，也要保留 secure 和 httpOnly。

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite

---

存储 JWT 整个问题的另一个角度：

JWT 永远不应该存储在你的 localStorage 实际上，它们甚至不应该存储在你的 cookie 中，除非你能够实现非常严格的 CSRF 保护

Checkout this for motivation

JWT 作为 id_token 就像您的用户凭据

JWT 作为 access_token 就像您的会话令牌

最安全的选项是内存中。 Checkout this for a deep dive

---

将访问令牌存储在内存中，并将刷新令牌存储在 cookie 中

为什么这对 CSRF 来说是安全的？

尽管向 /refresh_token 提交的表单会起作用并且会返回一个新的访问令牌，但如果攻击者使用的是 HTML 表单，他们就无法读取响应。为防止攻击者成功发出 fetch 或 AJAX 请求并读取响应，这需要正确设置授权服务器的 CORS 策略以防止来自未经授权的网站的请求。

你可以在这里读更多关于它的内容：

https://dev.to/cotter/localstorage-vs-cookies-all-you-need-to-know-about-storing-jwt-tokens-securely-in-the-front-end-15id

---

在 Web 浏览器中，您可以将 JWT 存储在本地/会话存储或 cookie 中。两者都有漏洞。您可以选择您喜欢的一个，但您应该将安全作为一个整体来保护，并且应该精心设计流程。如果你只阻止 XSRF 和 XSS，它不会帮助你。这是对您问题的简短回答。

首先，您要防止用户数据被盗。非常有问题的是 XSS 攻击。如果您使用存储，攻击者可以窃取令牌 - 将令牌发送到他的服务器并发出请求以窃取用户数据。如果你使用 httpOnly cookie，他不能窃取令牌，但他可以发送请求（浏览器包括 cookie，如果脚本在同一个域中），读取响应并将用户数据发送到他的服务器。结果是一样的。

为了防止将数据发送到具有不同域的服务器，您可以使用 Content-Security-Policy 标头。我建议研究所有安全标头和网络安全。好的资源是 OWASP。这个论坛不是要写很多页。

XSRF (CSRF)

如果您使用 cookie，则应用程序很容易受到这种攻击。

如何预防：

设置 httpOnly、secured 和 SameSite=strict 标志。您还可以使用不带 httpOnly 的第二个 cookie XSRF-TOKEN 并将其值与此 cookie 一起发送到标头 X-Xsrf-Token 中。但是如果浏览器支持，这可以通过 SameSite 标志解决。

跨站脚本

从某种意义上说，存储和 cookie 都容易受到 XSS 的攻击。使用 javascript 代码，您可以读取存储，并且您可以使用浏览器包含的 cookie 向服务器发送请求，因为您在同一个域中。如果您使用用户输入，您应该转义/清理它们。您还可以使用标头 x-xss-protection。最大的问题是 3rd 方 js 库中的恶意代码，因为您无法逃脱它并且它在同一个域上运行。您可以防止用户数据被您的错误窃取，但这样的代码可能会给您的应用程序和用户带来不同的问题。

---