CORS漏洞其中已经存在很久了，但是国内了解的人不是很多，文章更是少只有少，漏洞平台也没有此分类。
在DefConChina中，陈建军分享的议题中解释的更清楚，有意向的可以找PPT或者视频
owasp内的详细介绍
CORS，Cross-OriginResource Sharing，跨源资源共享。
CORS是W3C出的一个标准，其思想是使用自定义的HTTP头部让浏览器与服务器进行沟通。因为开发者需要进行跨域进行获取资源，应用场景，在a.com，想获取b.com中的数据，常用的2种方法进行跨域一种为JSONP,一种为CORS.还有html标签也能跨域，有以下几种img, iframe,ink, js等。
cors跨域访问资源示意图：
前面说了，设置了orgin就能进行跨域访问。而如果配置cors不当的话，如Access-Control-Allow-Orgin:的话，就有可能存在问题。
Access-Control-Allow-Origin这个字段的意思是允许跨域访问的网站，配置为的话，默认就能跨域访问所有网站，也就是说orgin这个字段是可控的。当然仅仅有一个orgin字段还不行，这里要说下Access-Control-Allow-Origin-Credentials这个字段。这个字段的意思是是否带cookie跨域访问网站,如果为true的话，就是允许带着cookie跨域访问b网站。所以说，如果攻击者把orgin:设置成自己搭建的网站，功能为接收受害者的cookie。而Access-Control-Allow-Origin-Credentials又设置成true,这时候我们就可以说存在漏洞了。
看到前面漏洞产生原因，主要是Access-Control-Allow-Orgin:kissing_heart:和Access-Control-Allow-Origin-Credentials:true这两个问题。有人可能要问了，这两个成立的话就会存在漏洞？答案是否定的。因为当你跨域的时候，浏览器看到你这两个的设置，会认为是不安全的，就是会拦截你的操作。而Access-Control-Allow-Orgin绑定了一个网站，但是对值没进行一个校验，也就是攻击者抓包把orgin改了，而网站没进行校验，就存在漏洞。
所以
Access-Control-Allow-Origin-Credentials: true
---可能存在漏洞
Access-Control-Allow-Orgin:*
Access-Control-Allow-Origin-Credentials: true
--- 不存在漏洞
1.互联网厂商的api接口
2.聊天的程序的api接口
3.app的api（不过有一些请求需要带有一些额外的请求头，利用起来比较困难）
4.区块链厂商
第一种：
当你看到的返回结果包括
则可能存在cors漏洞
第二种：
一些简单用法：
使用burp进行自动化检测
在burp下做如下设置
然后我们便可以使用过滤器查看是否存在cors漏洞
首先是一个这样的界面，然后我们抓包，发现有Orgin字段
我们把orgin改为其他地址试试
发现Access-Control-Allow-Orgin已经为我的博客地址并且Access-Control-Allow-Origin-Credentials:true。说明存在这个漏洞，此时我们便可以使用pocbox来获取他人的信息了。
将生成的poc发送给别人即可获取他人的信息。
当然，如果有兴趣的也可以去看一下hackerone上的一个案例：
客户端缓存中毒
这种配置允许攻击者利用其他的漏洞。
比如，一个应用返回数据报文头部中包含“X-User”这个字段，这个字段的值没有经过验证就直接输出到返回页面上。
NULL源
CORS的规范中还提到了“NULL”源。触发这个源是为了网页跳转或者是来自本地HTML文件。目标应用可能会接收“null"源，并且这个可能被测试者（或者攻击者）利用，意外任何网站很容易使用沙盒iframe来获取”null“源
<iframesandbox="allow-jss allow-top-navigation allow-forms"src='data:text/html,<js>**CORSrequest here**</js>’></iframe>
使用上面的iframe产生一个请求类似于下面这样
GET /handler
Host: target.local
Origin: null
如果目标应用接收”null"源，那么服务器将返回类似下面的数据报文
HTTP/1.1 200 OK
Acess-Control-Allow-Origin: null
Access-Control-Allow-Credentials: true
使用目标域名作为子域名
如果目标应用只检查只检查“Origin”中的字符串是否包含“target.local”，那么就可以在自己控制的服务器上创建一个子域名。用这样的方式，请求一般产生自JavaScript代码，并且请求中的“Origin”会像下面这样
注册一个同名的域名
假设，目标应用实现是基于下面的正则表达式去检测“Origin”头部的话：
^https?:\/\/.*.?target.local$
这个?只影响".“这个字符串，因此在“target.local”前面的任何字符串都是被允许的，而不管是否有”."把他们分开。因此，只需要在“origin”末尾包含目标域名就可以绕过上面的限制（这个场景的的目标域名是“target.local”），比如：
攻击者只需要注册一个末尾包含目标域名的新域名就可以利用这样的漏洞了。
（1）如果没有必要就不要开启CORS
（2）严格限制域白名单，而不是使用*
（3）尽量避免使用Access-Control-Allow-Credentials
（5）配置“VARY”头部
（6）如果可能的话避免使用“CREDENTIALS”
（7）限制缓存的时间
（8）限制使用的方法
原创文章未经授权禁止转载，谢谢合作
·END·