security - 使用JWT保护SPA的最佳做法

Question

背景

抱歉，这个问题有点开放性，但是我只是想了解它的工作原理，并且是该领域的新手。

我正在建立由(Apollo)服务器支持的SPA。这个问题与使用JWT Bearer token 的传统身份验证有关。我将假设服务器具有有效的TLS证书。

题

我将从写出我所理解的内容开始，如果发现任何错误，请纠正我。干杯!

用户注册。我们向SPA发送带有一些元数据的访问 token (例如exp)，并将其存储在httpOnly(以防止XSS)，SameSite=strict(以防止CSRF)，secure(以防止MITM攻击)cookie中。然后，它随每个身份验证请求一起发送，而不必查询数据库；如果我们将角色/作用域附加到JWT有效负载上，甚至可以进行授权，而不必查询用户数据库。

当用户尝试注销时会出现第一个问题。

问题1

使用httpOnly cookie注销用户的最佳做法是什么？ Here我读到最佳实践是设置两个cookie，一个不带有httpOnly(我猜是否具有相同的内容(JWT)？)，并且在服务器身份验证逻辑中都需要这两个cookie。当用户注销时，我们将删除非httpOnly，从而有效地注销用户。

问题2

如何处理多设备登录？我猜想JWT没有任何可识别设备的信息，因此只需在Cookie中发出新 token 即可。

到现在为止还挺好。

现在，假设上述 token 不会泄漏，我相信这是一个安全的系统。但是，实际上事情并不是那么简单。有人可以从无人看管的计算机中快速复制cookie数据。甚至可以使用USB记忆棒脚本来完成此操作，因为cookie只是文件系统中的文件。

问题3

有什么方法可以减轻这种情况？这里还有一些问题，以及我的扶手椅解决方案:)

3.1:浏览器是否具有用于安全加密cookie的API？如果是这样，我们可以加密cookie。我猜他们没有。

3.2:我有使用子网掩码和IP地址唯一标识设备的整个想法。但这可能行不通-我假设子网掩码未在诸如IP地址之类的http请求中携带，而在js中这样做将受到攻击者的摆布。最后，该对(IP，子网掩码)对于设备来说不是很好的标识符，因为断开连接后，另一台设备可以假定该子网掩码。 F * ck。

3.3:使用短暂的JWT。有点黑的解决方案imo。我们将JWT exp设置为15-30分钟，并假设在那段时间内，攻击者为can't cause much damage。诸如删除帐户之类的重要操作仍应使用密码(将通过https发送)，从而限制了攻击范围。 15分钟后，将提示用户重新登录，并可以还原所有效果或联系支持人员将其删除。

但是，出现了一个新问题:我们不希望用户每15分钟登录一次。我的理解到此为止:

3.3.1:使用保存为cookie的长寿命刷新 token -并没有太大变化。

3.3.2:在数据库中使用长期刷新 token 。好的，看起来很公平。用户一旦发现帐户中存在恶意行为，便可以联系支持人员，所有刷新 token 都将被删除，攻击者的剩余时间不到15分钟。实际上，我们只是对是否存在违规感兴趣，因此我们可以使用布尔值。为什么要烦恼刷新 token ？

恕我直言的问题是，攻击者仍然永远拥有访问权限。因此，我们仍然需要将其与设备的某些标识(用户代理，IP地址...)结合起来，从而带来额外的复杂性。

对于非关键(银行)应用程序，似乎最好的解决方案是仅使用寿命长的访问 token 。我将使用两个参数来证明该决定的合理性:

3.3.3:如果某人可以物理访问您的设备，则他们通常会做更糟糕的事情，然后复制cookie。

3.3.4:Facebook似乎使用6个月的访问 token ？至少表面上看起来是这样:我去了fb.com，删除了我的c_user cookie，cmd + r，登录名，并在6个月内创建了一个新的减去一些更改。但是我无法以有效的方式将Cookie从Brave复制到Chrome。我是在做错什么，还是有实际的好方法来防止这种攻击(无需在每个请求上都查询数据库)？

闭幕

很长的文字很抱歉，但是关于安全性有太多的困惑和不完整的答案，我只想确保自己做的一切正确。如果有人对我写的内容有任何评论或部分答案，我将非常感谢。我很高兴了解网络安全这个新领域!

Answer 1

这个问题有点太笼统了，但让我尝试回答几点。

如果您在不使用httpOnly且使用相同的JWT的情况下设置cookie，那么它很容易受到XSS的攻击，因此也没有httpOnly的意义。您可以向服务器发出请求，然后要求它为您删除Cookie。另请参阅下文。

当然，来自不同设备的同一用户只是另一个JWT。

此威胁并非特定于JWT，一个普通的旧 session ID可能以相同的方式被盗。对其进行加密无济于事，因为这样一来，加密的版本就会被盗，这就是身份验证所需的全部内容。而且，无论从哪里窃取 token ，密钥都必须是可用的。您通常不必处理此问题，客户端的物理安全性通常超出了典型Web应用程序的范围。您可以并且应该做的是，将短期访问 token 与长期刷新 token 一起发行，然后将它们分别存储为。

在许多用例中执行此操作的合理安全方式:

如果一个普通的旧 session ID(〜一个大的随机数)就足够了，请不要使用有意义的标记(信息不包括一个大的随机数)。通常是这样。

使用不同的来源进行身份验证(颁发 token )和服务(使用 token 进行身份验证)。 OpenID Connect(在某种程度上还包括Oauth2)具有身份提供者和服务提供者的这些概念。

可以将访问 token 存储在服务源的本地存储中，从而允许您的javascript访问身份信息和声明，并承担潜在XSS可以访问的风险。并非在所有应用程序中都如此，因此您必须评估这种风险!另外，将 token 存储在cookie中会使应用程序容易受到CSRF的攻击，SameSite仅能在最新的浏览器(大约在过去一年中发布)中运行，这可能还不够。对于您而言，这是否再次成为问题取决于您的用例和威胁模型。

刷新 token 可以存储在身份提供者来源的httpOnly cookie 中。因此，如果旧的不再起作用，则必须在应用程序中实施适当的错误处理，才能尝试从身份提供者那里获取新的访问 token 。

所有这些都应该在一个众所周知且经过测试的库中实现，因为要使其正确并不容易。您可以并且应该使用出色的身份解决方案(收费和免费)。