一、同源策略介绍
0x01 为什么需要同源策略
同源策略是浏览器的安全基石。同源策略保证了同一个浏览器打开不同网站，不同网站之间不会相互影响。例如:张三登陆了某合法网站，浏览器存储了他的cookie，而这时他又打开了另外一个网站，该网站会记录用户的cookie。如果没有同源策略，那么这个网站就会记录浏览器存储的cookie，此时银行网站的cookie也被记录，从而造成银行用户cookie泄露。
0x02 同源策略的条件
浏览器的同源策略规定：不同域的客户端脚本在没有明确授权的情况下，不能读写对方的资源。同源策略的三个要求:同协议、同域名、同端口，必须满足这三个要求。
二、CORS介绍
0x01 CORS介绍
CORS全称为Cross-Origin Resource Sharing，中文名称为跨域资源共享，这是一种浏览器机制，可实现对位于给定域外部的资源的受控访问。它扩展了同源策略(SOP)并增加了灵活性，它允许浏览器向跨源服务器发出XMLHttpRequest请求，从而克服了AJAX只能同源使用的限制，这样就可以使不同的网站可以跨域获取数据。
CORS与JSONP的使用目的相同，它们都是为了进行跨域请求。但是CORS比JSONP更强大。JSONP只支持GET请求，CORS支持所有类型的HTTP请求。JSONP的优势在于支持老式浏览器，以及可以向不支持CORS的网站请求数据。
0x02为什么需要CORS
在前面说到，同源策略可以避免不同网站同时打开造成信息泄露的问题，那么同源策略既然这么安全，为什么需要CORS呢？
随着Web应用程序和微服务使用的日益增长，出于实用目的往往需要将信息从一个子域传递到另一个子域，或者在不同域之间进行传递(例如将访问令牌和会话标识符，传递给另一个应用程序)。为了允许跨域通信，开发人员必须使用不同的技术来绕过SOP并传递敏感信息，因此，为了在不影响应用程序安全状态的情况下实现信息共享，在HTML5中引入了跨源资源共享(CORS)。但问题也随之而来，许多人为了方便干脆直接使用默认的配置，或是由于缺乏对CORS的了解而导致了错误的配置，这样攻击者就可以利用该漏洞获取到一些敏感的数据。
0x03 CORS两种跨域请求
CORS定义了两种跨域请求：简单请求 和 非简单请求。简单跨域请求就是使用设定的请求方式请求数据，而非简单跨域请求则是在使用设定的请求方式请求数据之前，先发送一个OPTIONS预检请求，验证请求源是否为服务端允许源。只有"预检"通过后才会再发送一次请求用于数据传输。
(1):简单请求
（1) 请求方法是以下三种方法之一： HEAD GET POST （2）HTTP的头信息不超出以下几种字段： Accept Accept-Language Content-Language Last-Event-ID Content-Type：application/x-www-form-urlencoded、 multipart/form-data、text/plain
只有同时满足以上两个条件时，才是简单请求，否则为非简单请求。
(2):非简单请求
非简单请求是那种对服务器有特殊要求的请求，比如请求方法是PUT或DELETE，或者Content-Type字段的类型是application/json。非简单请求的CORS请求，会在正式通信之前，增加一次OPTIONS方法的预检请求。
浏览器先询问服务器，当前网页所在的域名是否在服务器的许可名单之中，以及可以使用哪些HTTP动词和头信息字段。只有得到肯定答复，浏览器才会发出正式的XMLHttpRequest请求，否则就报错。
三、CORS漏洞判断
如何在渗透测试中发现CORS漏洞，这才是这篇文章的重点。
0x01 通过简单的观察进行判断
(1):四种情况说明
当我们进行测试时，看服务器响应头字段里可以关注这几个点，可以通过这两个字段后面的值来进行判断，简单判断是否存在CORS漏洞。
①最好利用的配置
Access-Control-Allow-Origin: https:Access-Control-Allow-Credentials: true
②可能存在可利用的配置
Access-Control-Allow-Origin: null Access-Control-Allow-Credentials: true
③很好的条件但无法利用
Access-Control-Allow-Origin: * Access-Control-Allow-Credentials: true
注意:重点说明的一点，对于上面这组配置组合，允许所有的网站进行访问，虽然看起来很完美，但是CORS机制已经默认自动阻止了这种组合，也就是说，如果在测试过程中，发现有这种配置组合，那么肯定不存在漏洞。这也算是CORS的最后一道防线。
④单一的情况
Access-Control-Allow-Origin：*
在这说明一点，对于有些网站配置如下，可能会存在CORS漏洞，但是由于Access-Control-Allow-Credentials的值设置为false，可能无法获取到敏感信息。
Access-Control-Allow-Origin: https:Access-Control-Allow-Credentials: false
(2):参数说明
-
Access-Control-Allow-Origin：该字段是必须的。它的值要么是请求时Origin字段的值，要么是一个*，表示接受任意域名的请求。
-
Access-Control-Allow-Credentials：该字段可选。它的值是一个布尔值，表示是否允许发送Cookie。默认情况下，Cookie不包括在CORS请求之中。当设置为true时，即表示服务器明确许可，Cookie可以包含在请求中，一起发给服务器。当这个值为false，则服务器不会给浏览器发送Cookie。
0x02 使用Origin判断是否存在CORS
CORS的漏洞主要看当我们发起的请求中带有Origin头部字段时，服务器的返回包带有CORS的相关字段并且允许Origin的域访问。一般测试WEB漏洞都会用上BurpSuite，而BurpSuite可以实现帮助我们检测这个漏洞。
Access-Control-Allow-Origin: foo.example.org Access-Control-Allow-Credentials: true
![CORS漏洞小结]( "CORS漏洞小结")
使用Origin来进行判断
![CORS漏洞小结]( "CORS漏洞小结")
四、CORS为什么会产生漏洞
0x01 最安全的配置
Access-Control-Allow-Origin: * Access-Control-Allow-Credentials: false
大家可能一看会觉得这个是最好利用的，因为所有的网站都可以访问，但是在前面也说过，在设计CORS时就考虑到这个问题了，如果Access-Control-Allow-Origin配置为*，那么默认将不允许获取网站数据的，并且Access-Control-Allow-Credentials设置为false，也将不能携带cookie，这就上了双层保险。
0x02 产生漏洞的配置
有一些网站的Access-Control-Allow-Origin他的设置并不是固定的，而是根据用户跨域请求数据的Origin来定的。这时，不管Access-Control-Allow-Credentials 设置为了 true 还是 false。任何网站都可以发起请求，并读取对这些请求的响应。意思就是任何一个网站都可以发送跨域请求来获得CORS服务端上的数据。如果Access-Control-Allow-Credentials这个字段设置成true，那么不但可以发起请求，而且还可以要求浏览器携带cookie，这将是非常危险的。
五、CORS漏洞修复
0x01 正确配置跨域请求
如果Web资源包含敏感信息，则应在Access-Control-Allow-Origin标头中正确指定来源。
0x02 只允许信任的网站
看起来似乎很明显，但是Access-Control-Allow-Origin中指定的来源只能是受信任的站点。特别是，使用通配符来表示允许的跨域请求的来源而不进行验证很容易被利用，应该避免。
0x03 避免将null列入白名单
避免使用标题Access-Control-Allow-Origin: null。来自内部文档和沙盒请求的跨域资源调用可以指定null来源。应针对私有和公共服务器的可信来源正确定义CORS头。
0x04 避免在内部网络中使用通配符
避免在内部网络中使用通配符。当内部浏览器可以访问不受信任的外部域时，仅靠信任网络配置来保护内部资源是不够的。
0x05 CORS不能替代服务器端安全策略
CORS定义了浏览器的行为，绝不能替代服务器端对敏感数据的保护-攻击者可以直接从任何可信来源伪造请求。因此，除了正确配置的CORS之外，Web服务器还应继续对敏感数据应用保护，例如身份验证和会话管理。
参考链接:
https://www.cnblogs.com/Xy--1/p/13069099.html
https://cloud.tencent.com/developer/article/1601688
![CORS漏洞小结]( "CORS漏洞小结")
原文始发于微信公众号（想走安全的小白）：CORS漏洞小结
评论