CORS跨域资源共享漏洞与JSONP劫持漏洞类似,都是程序员在解决跨域问题中进行了错误的配置。攻击者可以利用Web应用对用户请求数据包的Origin头校验不严格,诱骗受害者访问攻击者制作好的恶意网站,从而跨域获取受害者的敏感数据,包括转账记录、交易记录、个人身份证号信息、订单信息等等。
近几年在很多的渗透测试报告中,CORS跨域资源共享漏洞越来越多了。有的朋友实在挖不出漏洞,偶尔就会写上一个CORS跨域资源共享漏洞出一份报告,但是细究起来以下几个问题,却都模棱两可,搞不明白。
1. 什么是CORS漏洞?
2. 哪些情况下的CORS漏洞是高危漏洞?哪些情况下CORS漏洞是没有危害的?
3. CORS漏洞的怎么利用?
4. CORS漏洞的修补建议?
很多朋友以为Web应用返回Access-Control-Allow-Origin: *就是存在漏洞,其实这个判断是不完善的。本期ABC_123自己写了一个Java的测试环境,给大家演示一下CORS漏洞的复现过程及利用过程,相信大家一看就明白了。
Part2 CORS漏洞测试结果首先给出ABC_123的测试结果,以下结论是我自己写Java代码搭建环境进行测试给出的结论,欢迎大家批评指正。首先使用burpsuite抓包对http请求添加Origin: http://www.attacker.com进行测试:
1 如果返回头是以下情况,那么就是高危漏洞,这种情况下漏洞最好利用:
Access-Control-Allow-Origin: https://www.attacker.com
Access-Control-Allow-Credentials: true
2 如果返回头是以下情况,那么也可以认为是高危漏洞,只是利用起来麻烦一些:
Access-Control-Allow-Origin: null
Access-Control-Allow-Credentials: true
3 如果返回以下,则不存在漏洞,因为Null必须是小写才存在漏洞:
Access-Control-Allow-Origin: Null
Access-Control-Allow-Credentials: true
4 如果返回以下,可认为不存在漏洞,因为CORS安全机制阻止了这种情况下的漏洞利用,也可以写上低危的CORS配置错误问题。
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
5 如果返回以下,可认为不存在漏洞,也可以写上低危的CORS配置错误问题。
Access-Control-Allow-Origin: *
Part3 CORS跨域漏洞复现
首先复习一下常规的CORS漏洞测试过程:抓取一个能够返回个人敏感数据的HTTP请求包,添加Origin: http://www.xxx.com,查看返回头中是否包含“Access-Control-Allow-Origin: *”、“Access-Control-Allow-Credentials: true”,这里说明一点,如果返回包中这两个头同时存在,那么它其实是不存在CORS漏洞的。接下来依据Access-Control-Allow-Origin、Access-Control-Allow-Credentials的不同返回值的各种情况,分别写Java代码测试一下,是否能够获取敏感数据,大家就明白了。
接下来我用Java编写了两个Servlet代码模拟一个Web购物网站,用JS前端代码模拟攻击者构造的CORS漏洞利用html页面。
如下所示,首先是登录界面的servlet代码如下。
代码效果如下,用户输入用户名密码后,购物网站提示登录成功,这时候后台代码已经生成Cookie。
接下来用户访问PersonInfo页面,http://192.168.237.1:9999/Servlet/PersonInfo 会显示交易密码是123456。
此页面对应的PersonInfo的Sevlet代码如下:
接下来攻击者为了获取该购物网站用户的交易密码,精心构造了如下的attack.html页面放到Web服务器上,此时攻击URL是http://www.attacker111.com/attack.html。攻击者将此URL发给受害者浏览,受害者的交易密码将会被获取到。
首先看第1种情况,服务器返回如下消息头,这种情况下,非常好利用,所以漏洞定级是高危:
Access-Control-Allow-Origin: https://www.attacker.com
Access-Control-Allow-Credentials: true
这两个返回头表示应用程序允许来自任何Origin的任何脚本向应用程序发出CORS请求,这时候程序员的代码是这样写的:
受害者访问攻击者构造好的URL之后,成功获取用户的敏感数据。
F12查看浏览器发出的请求,发现其带上了Cookie,成功绕过跨域的同源限制。
服务器返回如下消息头,这种情况下,利用起来稍有困难,这里的null必须全部都是小写,漏洞仍然是高危。
Access-Control-Allow-Origin: null
Access-Control-Allow-Credentials: true
在这种情况下,应用程序HTTP响应头Access-Control-Allow-Origin的值始终为null。当用户指定null以外的任何值时,应用程序不会处理。
这时候访问http://192.168.237.199/attack.html,发现浏览器提示CORS策略错误。
因为这时候的Origin不等于null
这里需要想办法让Origin等于null,于是攻击者构造如下js代码:
此时发现仍然可以成功获取用户的敏感数据。
服务器返回如下消息头,这种情况下,其实是不存在漏洞的,如果非要牵强地说存在漏洞,可以协商CORS配置错误,毕竟设置为*本身就有问题。
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
对应着java代码如下:
访问http://www.attacker111.com/attack.html发现,浏览器直接报错,看来这种情况根本不被安全策略所允许。
服务器返回如下消息头,这个就不演示了,只能说明CORS配置存在问题,但是没法获取敏感数据,漏洞评级应为中危或者低危。
Access-Control-Allow-Origin:*
接下来换谷歌Chrome浏览器最新版本下测试,发现确实成功绕过了同源策略,发起了跨域请求,但是Chrome浏览器却没有为请求带上Cookie,所以漏洞利用有限。
1. Access-Control-Allow-Origin中指定的来源只能是受信任的站点,避免使用Access-Control-Allow-Origin: *,避免使用Access-Control-Allow-Origin: null,否则攻击者可以伪造来源请求实现跨域资源窃取。
2. 严格校验“Origin”值,校验的正则表达式一定要编写完善,避免出现绕过的情况。
3. 减少“Access-Control-Allow-Methods”所允许的请求方法。
4. 除了正确配置CORS之外,Web服务器还应继续对敏感数据进行保护,例如身份验证和会话管理等。
专注于网络安全技术分享,包括红队攻防、蓝队分析、渗透测试、代码审计等。每周一篇,99%原创,敬请关注
Contact me: 0day123abc#gmail.com(replace # with @)
你是否还在寻找稳定的海外服务器提供商?创新互联www.cdcxhl.cn海外机房具备T级流量清洗系统配攻击溯源,准确流量调度确保服务器高可用性,企业级服务器适合批量采购,新人活动首月15元起,快前往官网查看详情吧
当前标题:第40篇:CORS跨域资源共享漏洞的复现、分析、利用及修复过程-创新互联
当前地址:https://www.cdcxhl.com/article28/deoejp.html
成都网站建设公司_创新互联,为您提供动态网站、商城网站、响应式网站、网站维护、网站制作、全网营销推广
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联