设置访问控制允许原产地接受所有域时存在哪些安全风险？

Question

我最近不得不将访问控制允许Origin设置为*，以便能够进行跨子域AJAX调用。我觉得这可能是个安全问题。如果我保持这种设置，我将面临什么样的风险？

Answer 1

另外，Access Control Allow Origin只是从服务器发送到浏览器的http头。将其限制在特定地址（或禁用）并不会使您的站点更安全，例如，对于机器人。如果机器人愿意，他们可以忽略标题。默认情况下，常规浏览器（Explorer、Chrome等）都会使用标题。但是像Postman这样的应用程序会忽略它。

当服务器端返回响应时，它实际上不会检查请求的“起源”。它只是添加了超文本传输协议头。发送请求的浏览器（客户端）决定读取访问控制头并对其采取行动。请注意，在XHR的情况下，它可能会使用一个特殊的“选项”请求来首先询问标头。

因此，任何具有创造性脚本编写能力的人都可以轻松忽略整个标题，不管其中设置了什么。

另请参阅设置访问控制允许来源的可能安全问题。

现在来回答这个问题

我情不自禁地感到，我正在将我的环境置于安全风险之中。

如果有人想攻击你，他们可以轻松绕过访问控制。但通过启用“*”，您确实为攻击者提供了更多的“攻击向量”，例如，使用支持该HTTP头的常规WebBrowser。

Answer 2

访问控制允许源代码：完全可以安全地添加到任何资源，除非该资源包含由标准凭据以外的内容保护的私有数据。标准凭据是cookie、HTTP基本身份验证和TLS客户端证书。

想象一下https://example.com/users-private-data，这可能会根据用户的登录状态公开私有数据。此状态使用会话cookie。将访问控制允许来源：添加到此资源是安全的，因为此标头仅允许在请求没有cookie的情况下访问响应，并且获取私有数据需要cookie。因此，没有私人数据泄露。

想象一下https://intranet.example.com/company-private-data，公开私人公司数据，但只有在公司的wifi网络上才能访问。将访问控制允许源代码：添加到此资源是不安全的，因为它使用标准凭据以外的内容进行保护。否则，一个糟糕的脚本可能会将您用作内部网的通道。

想象一下，如果用户在一个匿名窗口中访问资源，他们会看到什么。如果您对每个人都看到此内容（包括浏览器收到的源代码）感到满意，则可以添加访问控制允许源代码：。

Answer 3

通过使用Access-Control-允许-起源：*响应，请求的资源允许与每个起源共享。这基本上意味着任何站点都可以向您的站点发送XHR请求并访问服务器的响应，如果您没有实现此CORS响应，情况就不会如此。

因此，任何网站都可以代表其访问者向您的网站提出请求，并处理其响应。如果您实现了基于浏览器自动提供的内容（cookie、基于cookie的会话等）的身份验证或授权方案，则第三方站点触发的请求也将使用它们。

这确实会带来安全风险，特别是如果您不仅允许对所选资源共享资源，还允许对每个资源共享资源。在这种情况下，你应该看看什么时候启用CORS是安全的？。

当前获取标准在凭据模式设置为包括时省略凭据，如果访问-控制-允许-起源设置为*。

因此，如果使用基于cookie的身份验证，则不会在请求中发送凭据。