Access-control-allow-origin:*并没有实际危害（更新）

一、网站一般在需要共享资源给其他网站时（跨域传递数据），才会设置access-control-allow-origin HTTP头。而跨域传递数据也可以使用jsonp方式

 

二、如果www.a.com域设置了access-control-allow-origin:* http头, 其他任何域包括www.b.com域的js就可以使用Ajax技术读取到​www.a.com域的数据

三、根据w3c标准：​http://www.w3.org/TR/cors/#resource-requests，如果www.b.com域下js要读取到www.a.com域下的需要登录才能访问的资源，需要www.a.com域同时设置了 Access-Control-Allow-Credentials: true头（即允许third-party cookie）

并且如果设置access-control-allow-origin为*星号（任何域），则Access-Control-Allow-Credentials头是不能设置为true的，如下图，参见​http://www.w3.org/TR/cors/#resource-requests

 

所以理论上网站设置了​Access-control-allow-origin: *，并没有实际危害，因为并不能跨域读取私密数据（登录后才可见数据）

 

四、然而否存在实际危害取决于浏览器是否遵循该标准（chrome、firefox等主流浏览器均遵循）

浏览器发出​跨域请求时，若Ajax没有setRequestHeader，则会直接发出请求，根据响应头中的access-control-allow-origin是否设置允许当前域（设置*，即允许任何域），来决定是否将数据交给js处理（其实数据已经返回到浏览器，但页面js无法拿到）

另外若同时设置了星号和withCredentials，浏览器也会拒绝将数据返回到js。浏览器在这个层面上是安全的

但是浏览器插件却往往会忽略http header的设置，比如postman​，不免有其他利用方式。

所以服务器应设置白名单。（使用jsonp跨域共享资源存在更多风险，有机会写写jsonp）

五、测试使用的代码如下http://localhost/test.htm，发送请求到http://127.0.0.1/对于浏览器来说就是在跨域，方便测试

 

ps:​ setRequestHeader需要在open之后调用。如果调用了setRequestHeader，浏览器会先发出OPTION请求到目标网站，确认是否设置Access-Control-Allow-Headers: content-type等。默认ajax发送数据为form格式，发送json格式数据需要服务器设置过Access-Control-Allow-Headers: content-type头才行

 

update：发现许多网站会根据请求头中的Origin值然后设置Access-control-allow-origin，且同时设置了Access-Control-Allow-Credentials为true，导致可以被黑客利用

Access-control-allow-origin:null 是可以携带cookie的

======================分割线=================

六、不携带cookie的利用姿势

以上说的Access-control-allow-origin: *情况，是不能跨域读取（需cookie认证的）隐私数据。

但也存在特定场景下不需要cookie也能攻击的：

》基于ip认证的资源跨域读取

》缓存投毒，增加Vary: Origin http头可以避免

 

 

===================2021/2/20更新===========

由于samesite cookie，此类攻击威力大打折扣，见文章samesite cookie防御CSRF漏洞_zzzzfeng的博客-CSDN博客