CORS跨源资源共享和Json Web Token

Posted 2021-04-19

在我的应用程序中，我包含了来自不同服务器/域的页面。为简单起见，我将参考我的主要应用程序Web A和其他Web B.

在某个地方，用户登录后，我将使用CORS和jwt从B加载页面。在A中，我创建了一个传递给Ajax的编码令牌。 Ajax在Header中添加了这个令牌（“Authorization”= bearer + encoded token）。

B然后使用此令牌解码并获取它所属的usersId和组，并确定用户是否有权访问该资源。此外，Web B中还有一个Access-Control-Allow-Origin = Web A设置，仅接受来自A的请求。

我的问题是关于CORS的安全部分和jwt的使用。在开发过程中，当使用Postman直接访问B中的资源时，我可以轻松绕过“Access-control-allow-origin”。只要我有正确的令牌，资源就会被送回来没有问题！我的意思是只需要一些潜在的黑客获取该编码的字符串，他们就可以轻松地使用Postman查看资源。

在涉及安全部分时，下一步是什么，因为我完全迷失了！

希望我能清楚地解释这个问题。所有帮助都非常感谢

答案

在攻击者获取用户的JWT访问令牌并直接从Web B请求资源的情况下，CORS并不意味着保护您。

实际上，CORS根本不是一个安全功能，而是一种安全地绕过浏览器的同源策略的方法，这是一种安全功能。同源策略（基本上每个浏览器都实现）限制网页访问来自不同源的网页上的数据。

想象一下浏览器没有实现同源策略的情况。任何网页都可以从任何来源请求数据，这意味着任何恶意网站都可以从银行，电子邮件帐户或其他任何地方请求数据。这个浏览器很乐意发送与这些来源相关的任何HTTP cookie，并且所有这些请求都将被授权。对这个浏览器的攻击是微不足道的。

因此，很明显，任何浏览器都需要同源策略。但是，正如您所知，网站在原始数据库之间共享数据通常很有用。这就是CORS规范创建的原因。只要双方同意共享数据跨越原点，浏览器就会允许发送请求。

要回答您的真实问题，阻止攻击者直接使用JWT的方法是不允许他们首先访问它。您应该像保存HTTP会话cookie或密码一样保护JWT，因为它就是这样。

另一答案

这是完全正确的。 CORS的存在是为了保护用户的Web浏览器。直接浏览或卷曲到站点B不受CORS保护。服务器可以从各种客户端获得任何类型的请求，并且必须自己保护。

站点B的安全性来自正确使用JWT（最好通过HTTPS）。首先，令牌用秘密签名。这可以让你知道其他人没有改变它或自己创建一个。其次，有效载荷应包括相对较短的到期时间。在这段时间之后，令牌的接收者应该忽略它，因此掌握令牌的中间人很少有时间使用它。第三，如果你只通过HTTPS传递令牌，那么你很少有人能够获得它。