例如：受cookie保护的数据是安全的

Question

我最近不得不将Access-Control-Allow-Origin设置为*，以便能够进行跨子域的ajax调用。
现在我不禁觉得我的环境存在安全隐患如果我做错了，请帮助我。

Answer 1

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

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

这确实带来了安全风险，特别是如果您不仅允许资源共享，而且仅限于所选资源，而不是资源共享。在这种情况下，您应该查看 When is it safe to enable CORS? 。

Answer 2

Access-Control-Allow-Origin: *绝对可以安全地添加到任何资源中，除非该资源包含受标准凭据（Cookie，基本身份验证，TLS客户端证书）以外的内容保护的私有数据。

例如：受cookie保护的数据是安全的

想象一下https://example.com/users-private-data，它可能会根据用户的登录状态公开私有数据。此状态使用会话cookie。将Access-Control-Allow-Origin: *添加到该资源是安全的方法，因为只有在没有Cookie的情况下发出请求，并且要求使用Cookie来获取私有数据时，此标头才允许访问响应。结果，不会泄露任何私人数据。

例如：受位置/ ip /内部网络保护的数据并不安全（不幸的是，内部网和家用电器很常见）：

想象一下https://intranet.example.com/company-private-data，它公开了私人公司的数据，但是只有当您在公司的wifi网络上时，才能访问该数据。将Access-Control-Allow-Origin: *添加到此资源不安全，因为使用标准凭据以外的其他内容对其进行了保护。否则，错误的脚本可能会将您用作通往Intranet的隧道。

经验法则

想象一下，如果用户在隐身窗口中访问资源，将会看到什么。如果您对所有人看到此内容（包括浏览器收到的源代码）感到满意，则可以添加Access-Control-Allow-Origin: *。

Answer 3

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

服务器端在返回响应时实际上不会检查请求的“来源”。它只是添加了http标头。它是发送请求的浏览器（客户端），该请求决定读取访问控制头并对其进行操作。请注意，在XHR的情况下，它可能会使用特殊的“OPTIONS”请求来首先请求标题。

因此，任何具有创造性脚本功能的人都可以轻松忽略整个标题，无论其中设置什么。

另见Possible security issues of setting Access-Control-Allow-Origin。

现在实际回答问题

我情不自禁地觉得我的环境是安全的风险。

如果有人想要攻击你，他们可以轻松绕过Access-Control-Allow-Origin。但是通过启用“*”，您可以为攻击者提供更多“攻击媒介”，例如，使用支持HTTP标头的常规网络浏览器。

Answer 4

以下是作为评论发布的2个示例，当通配符确实存在问题时：

假设我登录银行的网站。如果我去另一页然后回到我的银行，我仍然因为cookie而登录。其他互联网上的用户可以像我一样在我的银行点击相同的网址没有cookie，他们将无法访问我的帐户。如果允许跨域请求，恶意网站可以有效冒充用户。

- Brad

假设您有一个普通的家庭路由器，例如Linksys WRT54g或一些东西。假设路由器允许跨源请求。一个脚本在我的网页上可以向公共路由器IP地址发出HTTP请求（如192.168.1.1）并重新配置您的路由器以允许攻击。它甚至可以将您的路由器直接用作DDoS节点。（大多数路由器都有测试允许ping或简单HTTP服务器检查的页面。这些可以集体滥用。）

- Brad

我认为这些评论应该是答案，因为他们用reallife示例解释了这个问题。

Answer 5

在服务器尝试通过设置以下标头来完全禁用CORS的情况。

Access-Control-Allow-Origin：*（告诉服务器接受的浏览器来自任何起源的跨站点请求）
Access-Control-Allow-Credentials：true（告诉浏览器网站请求可以发送Cookie）

在浏览器中实现了故障安全，将导致以下错误

"Credential is not supported if the CORS header ‘Access-Control-Allow-Origin’ is ‘*’"

因此，在大多数情况下，将“访问控制允许来源”设置为*不会有问题。但是，为了防止受到攻击，服务器可以维护允许的来源列表，并且每当服务器收到跨来源请求时，它都可以针对允许的来源列表验证ORIGIN标头，然后在Access-Control-Allow-Origin中回显相同的名称标头。

由于浏览器上运行的javascript无法更改ORIGIN标头，因此恶意网站将无法对其进行欺骗。

设置Access-Control-Allow-Origin有哪些安全隐患？

5 个答案:

例如：受cookie保护的数据是安全的

例如：受位置/ ip /内部网络保护的数据并不安全（不幸的是，内部网和家用电器很常见）：

经验法则