如何在你的应用程序中处理你的 JWT？

AWS 安全上线！

这个问题在互联网上是个敏感话题。无论你在哪里，人们都倾向于非常教条。

- 不要将其存储在本地存储中!!!您不知道 XSS 攻击吗？！
- 请不要再相信将您的 JWT 存储在 HttpOnly cookie 中是安全的........您仍然容易受到 XSRF 攻击。

你明白了。

长话短说，我正在寻找一些信息来自己构建一个强大的身份验证系统。我对上面提到的攻击一无所知，当然也不知道如何保护我的应用程序。

我会尽力总结我学到的知识，包括不同的技巧以及它们的后备方案。本文也将尽量保持客观。

不用多说，让我们开始吧。

问题是什么 ？

免责声明：为了重点介绍 JWT 的安全部分，我将特意简要介绍一下它。您可以访问其专门的网站了解更多信息。

因为有一个。

假设你正在搭建一个新网站，现在正处于身份验证阶段。经过一番研究，你发现（截至撰写本文时）最常用的方法就是使用 JWT ，即Json Web token。

JWT 本质上是一个编码字符串，其中包含一些基本信息（任何你想要的信息）。当你登录时，服务器会将其返回给你；客户端在后续任何需要身份验证的请求中也需要提供它，以便服务器能够接受。
简而言之，JWT 是一种向服务器证明你的用户合法且已通过身份验证的方式。

那么..如果我们需要在任何需要身份验证的进一步请求中提供 JWT，我们应该在哪里撕毁它？

这就是事情变得有趣的地方。

本地存储

我的第一个想法，我相信和很多人一样，是将新获取的 JWT 存储在浏览器的本地存储中。操作很简单，如下：

localStorage.setItem('jwt', jwtYouReceive);

每当我们需要它时：

localStorage.getItem('jwt');

尽管这是存储 JWT 最简单的方法，但事实证明，这是迄今为止最不安全的方法。
本质上，localStorage 中存储的所有内容都可以通过 JavaScript 代码访问。这意味着，如果黑客能够以某种方式在我们的网站中执行一些 JS 代码，他就可以窃取 JWT，并且他的任何请求都会被接受为已认证用户。其中一种方法是通过XSS攻击。

XSS攻击

跨站脚本

简单来说，XSS 攻击是指网站内部执行了一些恶意代码。这种攻击可能像 console.log 一样温和，但也可能严重到窃取信息，例如我们的 JWT。

让我们举一个非常牵强的例子来更好地理解它。

很简单，对吧？现在问题来了，通过表单发送的数据没有经过安全过滤（这意味着任何不安全或不相关的数据都会被删除或转义），因此黑客可能会插入有害脚本。

<div>
    I juste created an amazing blog post !! 
    <script>functionToReadYourJWTandSendItToMe()</script> 
    Please, accept it !
</div>

这会插入到数据库中，当管理员打开页面查看博客文章的预览时，脚本将被隐藏并执行，成功窃取管理员 JWT！

如果管理员接受博客文章，并将其显示在网站主页上，则每个打开该页面的访问者都会执行该脚本..窃取每个人的 JWT！

以下是回顾：

如果在没有适当的 XSS 防御措施的情况下将 JWT 存储在 localStorage 中，后果可能不堪设想，黑客可能会在你的网站上大范围地进行攻击，试图找到漏洞。
现在，开发人员有责任检查所有可能的漏洞，并在开发新功能时保持警惕。

有一些方法可以保护我们的应用程序免受 XSS 攻击，例如清理进入数据库的所有内容。

这是一个易于实施但有一定风险的解决方案。

第二种解决方案。

HttpOnly Cookie

在进一步挖掘 localStorage 的信息时，我发现很多人建议将 JWT 存储在HttpOnly Cookie 中。如果您不确定 Cookie 是什么，可以参考MDN文档。

需要注意的是，HttpOnly属性是最重要的部分。没有 HttpOnly 属性的 Cookie 可能会被某些 JS 代码读取，从而导致 XSS 问题。

通过应用该属性，我们将此 cookie 的使用限制为仅用于 HTTP 请求，从而完全防止 XSS 攻击。

但是...我们现在容易受到 XSRF 攻击。

XSRF攻击

跨站请求伪造

顾名思义，此类攻击的目标是在恶意网站上创建请求，并在目标网站上执行。让我们通过一个真实案例来更好地理解它。

您已打开网站并登录。您的 JWT 已安全地存储在 HttpOnly cookie 中，这意味着您发送到服务器的每个请求都将自动包含该 cookie，以及您的 JWT。

与每个拥有用户帐户的应用程序一样，您可以通过填写表单来更改某些信息。这将向您的服务器发送一个请求，服务器将验证您的 JWT，并允许更改。

当你导航到它时，你收到了一封电子邮件。你打开一个新标签页，打开电子邮件，然后点击链接。

☠️ 你借贷的网站有一个脚本，只要你打开页面就会执行。这个脚本是提前准备好的，它会在你的网站上执行请求。☠️
怎么做到的？黑客可以创建一个账户，打开开发工具，然后查看你服务器的端点。

基本上，黑客发送的请求和你一样，但他控制了信息。你的用户名、头像……甚至密码都可能被更改。

这次攻击最令人惊奇的部分是黑客不必恢复 JWT，它会自动包含在 HTTP 请求中。

有一些方法可以保护您的网站免受此类攻击，我们在这里就不介绍了，但大多数方法都容易受到..XSS 攻击。

第三种解决方案。

将其存储到内存中

也许比 localStorage 更简单的解决方案，目标也很简单。只需将 JWT 赋值给一个变量，即可根据需要使用。

const jwt = ...;

黑客无法通过 XSS 或 XSRF 攻击来获取此变量。

如此简单的解决方案却有一个严重的缺点：每当用户关闭您的网站时，下次回来时，他都需要再次登录，从而造成非常糟糕的用户体验。

就像其他解决方案一样，也有方法可以减轻其负面影响。

拥有 refresh_token

当你请求初始 JWT 时，计划是获取一个额外的令牌，即refresh_token令牌（本质上是一个有效期更长的 JWT）。此令牌将保存在浏览器中的 HttpOnly Cookie 中，以及服务器的数据库中。其目标是让用户保持登录状态，而无需在 JWT 每次过期时重新进行登录流程，这种过程称为静默刷新。

我们实际上可以利用这种行为来假装用户会话被持久化。由于 refresh_token 存储在 Cookie 中，我们可以跨会话使用它。当我们的网站启动时，我们会触发对特定端点的调用，只有当 refresh_token 仍然有效时，该端点才会返回 JWT。

- 如果 refresh_token 也是 JWT，安全性如何？
refresh_token 只会在特定端点上使用和接受。尝试用它访问 API 的其余部分将会失败。

- 但是黑客可以使用 XSRF，对吧？
是的，但是他无法看到返回的 JWT。

这种方法会导致大量的样板和开销。

总结

上述解决方案都不是万无一失的，总有办法让聪明的攻击者入侵。有些解决方案更容易实现，有些则需要更多设置，但可以提供可以说更好的整体“保护”。

选择最适合您的。

我希望它能像我写这篇文章一样帮助您理解这个极其复杂的主题。

您可以在Othrys 网站上找到原始文章，也可以关注我的Twitter或在这里标记我来讨论这篇文章。