CORS 跨域资源共享和 Json Web Token答案

【问题标题】：CORS Cross-origin resource sharing And Json Web TokenCORS 跨域资源共享和 Json Web Token
【发布时间】：2017-12-20 00:44:12
【问题描述】：

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

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

B然后使用这个token来解码获取userId和所属的group，判断user是否可以访问资源。此外，Web B 内部还有一个 Access-Control-Allow-Origin = Web A 设置，只接受来自 A 的请求。

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

说到安全部分，下一步是什么，因为我完全迷路了！

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

【问题讨论】：

你有没有想过这个问题？我目前想做和你类似的事情。我想创建一个客户可以在他们的网站上使用的小部件。我只希望在我的网站上创建帐户的客户能够使用返回小部件的 api。

标签： security https http-headers cors jwt

【解决方案1】：

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

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

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

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

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

【讨论】：

感谢您的评论并帮助 Micheal Davis 和 @MattS。目前我在 Ajax 中使用此承载令牌，因此编码令牌在浏览器的开发工具中可见。保护 JWT 是否涉及将其传递给其他地方的标头，而不是在 Ajax 调用内部？这样以后，通过使用 HTTPS，获取令牌变得更加困难？

【解决方案2】：

这完全正确。 CORS 的存在是为了保护用户在其 Web 浏览器中的安全。直接浏览或卷曲到站点 B 不受 CORS 保护。服务器可能会收到来自不同客户端的任何类型的请求，并且必须保护自己。

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

【讨论】：