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等

 

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头可以避免

展开阅读全文

没有更多推荐了,返回首页