JSONP 在 CORS 平台中的位置是什么？

Question

我正在研究 CORS 攻击、XSS 和 JSONP 以及跨源嵌入模型，以获取有关跨源资源共享的信息。但我不清楚 JSONP 逻辑。我是这个话题的新手。任何人都可以使用 JSONP 进行攻击吗？我们如何防止这种攻击？你能解释一下 CSRF 令牌吗？

Answer 1

从安全角度来看，JSONP 有点狡猾：

• 需要过度信任。假设您在 a.com 上托管了一个页面，它使用 JSONP 访问 b.org 提供的服务。这包括对 b.org 给予 100% 的信任。如果 b.org 是恶意的或有漏洞的，它可以破坏嵌入页面和所有 a.com 来源的安全性。从安全角度来看，这种过度信任是危险的：它会使您的应用程序变得脆弱。

• 换一种说法：JSONP 基本上是一个自我造成的 XSS。是的，好的，我知道这是一个功能，而不是错误，但仍然......

• CSRF 漏洞。您必须记住防御 CSRF 漏洞，而使用 JSONP，这有点棘手。标准建议是确保只有 POST 请求可以触发副作用，并在所有 POST 请求中包含 CSRF 令牌；但是 JSONP 涉及发送 GET 请求以触发副作用，这并不是您见过的最干净的解决方案。所以这意味着提供 JSONP 服务的主机需要记住即使在 GET 请求上也要检查 CSRF 令牌。此外，嵌入页面 (a.com) 需要一些棘手的协议才能从 JSONP 服务 (b.org) 获取正确的 CSRF 令牌。它变得一团糟。

• 导致混合内容警告。假设我们有一个托管在https://a.com 上的页面，它访问http://b.org 上的JSONP 服务。那么这将不可避免地触发一个看起来很吓人的混合内容警告（因为 JSONP 涉及从 http://b.org 加载脚本）。

• 用户身份验证变得丑陋。如果 b.org 想要对用户进行身份验证，那么在使用 JSONP 时会变得很棘手。在访问 b.org 的 JSONP 服务之前，嵌入页面 (a.com) 需要先以某种方式让用户有机会提前登录 b.org。两个站点需要协调。

据我了解，以下是 JSONP 安全问题的摘要：

从消费者的角度来看：

• 您必须相信提供程序不会返回恶意 JavaScript，而不是您指定的 JSONP 回调中包装的预期 JSON。 任何第三方 JavaScript 嵌入式附加组件也是如此，例如 Google Analytics。 它与 XSS 攻击的唯一相似之处在于它允许第 3 方在您的应用程序中执行任意 JavaScript，但是，您必须首先通过发出请求来选择信任第 3 方。

从提供者的角度来看：

• 您不得假设即使请求中存在客户的 cookie，消费者也是您控制的网页。根据授权 URL 的白名单检查 Referer 标头，和/或不要依赖基于 cookie 的身份验证。 类似于 CSRF / 混淆代理攻击。