javascript - 将所有域添加到 CORS 的安全隐患(访问控制允许来源 : *)

Question

据说不是将所有域都添加到CORS , 应该只添加一组域。然而，有时添加一组域并非易事。例如。如果我想公开一个 API，那么对于每个想要调用该 API 的域，我都需要联系我将该域添加到允许的域列表中。

我想在安全隐患和减少工作之间做出有意识的权衡决定。

我看到的唯一安全问题是 DoS attacks和 CSRF攻击。CSRF 攻击已经可以通过 IMG 元素和 FORM 元素来实现。可以通过阻止引用 header 上的请求来克服与 CORS 相关的 DoS 攻击。

我是否遗漏了安全隐患？

===编辑===

• 假定未设置 Access-Control-Allow-Credentials header
• 我知道如何添加给定的域列表“CORS 访问”，因此我只对添加所有域“CORS 访问”的安全隐患感兴趣

Answer 1

跨站点请求伪造攻击无疑是 Access-Control-Allow-Origin 解决的主要问题。

Ryan 关于内容检索当然是正确的。但是，关于提出请求的主题，这里还有更多要说的。许多网站现在提供 RESTful Web 服务，这些服务公开了可能涉及在后端进行重大更改的各种功能。通常，这些 RESTful 服务旨在使用 XHR(例如 AJAX)请求(可能使用“Single Page Application”作为前端)来调用。如果用户在访问恶意第三方站点时有一个事件 session 授予对这些服务的访问权限，则该站点可能会尝试在幕后调用这些 REST 端点，传递可能危及用户或站点的值。根据 REST 服务的定义方式，有多种方法可以防止这种情况发生。

在单页应用程序的 REST Web 服务的特定情况下，您可以指定对后端 REST 端点的所有请求都使用 XHR 进行，并拒绝任何非 XHR 请求。您可以通过检查是否存在自定义请求 header (类似于 jQuery 的 X-Requested-With)来决定这一点。只有 XHR 类型的请求才能设置这些 header ；来自表单和嵌入式资源的简单 GET 和 POST 请求不能。最后，我们想要指定 XHR 请求的原因让我们回到了最初的问题——XHR 请求受 CORS 规则的约束。

如果您允许 Access-Control-Allow-Origin: *，那么任何站点都可以代表用户向您的 REST 端点发出任何 AJAX 请求。如果您的 REST 端点涉及任何类型的敏感数据或允许数据持久化，那么这是一个 Not Acceptable 安全漏洞。相反，像我描述的那样强制执行仅限 XHR 的请求，并定义允许发出这些请求的来源白名单。

值得指出的是，如果您的 REST 端点不公开任何敏感信息，或者如果它们不允许用户进行任何持久性数据更改，则 Access-Control-Allow-Origin: * 可能是合适的决定。例如，谷歌地图提供了对公共(public) map 数据的只读 View ；没有理由限制可能希望调用这些服务的第三方站点。