第40篇：CORS跨域资源共享漏洞的复现、分析、利用及修复过程-创新互联

b995aad3ea4247c2d8d00cac0e69682b.png

创新互联专业为企业提供宿城网站建设、宿城做网站、宿城网站设计、宿城网站制作等企业网站建设、网页设计与制作、宿城企业网站模板建站服务，10余年宿城做网站经验，不只是建网站，更提供有价值的思路和整体网络服务。Part1 前言 

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漏洞的测试过程

首先复习一下常规的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代码测试一下，是否能够获取敏感数据，大家就明白了。

5ad4f46b34315d98123da545f4dabd86.png

  • 编写Java代码测试

接下来我用Java编写了两个Servlet代码模拟一个Web购物网站，用JS前端代码模拟攻击者构造的CORS漏洞利用html页面。

如下所示，首先是登录界面的servlet代码如下。

4f2b5ca2ccf31cfc77c9788c7a212be1.png

代码效果如下，用户输入用户名密码后，购物网站提示登录成功，这时候后台代码已经生成Cookie。

43abfd800c68fb1014b34aa0e645441d.png

接下来用户访问PersonInfo页面，http://192.168.237.1:9999/Servlet/PersonInfo 会显示交易密码是123456。

1d56e910766e7762b4f8f56c48d423c4.png

此页面对应的PersonInfo的Sevlet代码如下：

d59f6302381f210a5c6f9886c82d3780.png

接下来攻击者为了获取该购物网站用户的交易密码，精心构造了如下的attack.html页面放到Web服务器上，此时攻击URL是http://www.attacker111.com/attack.html。攻击者将此URL发给受害者浏览，受害者的交易密码将会被获取到。

1ee100d5a157f1ecf5581991b1a7f0fb.png

  • 第1种情况：

首先看第1种情况，服务器返回如下消息头，这种情况下，非常好利用，所以漏洞定级是高危：

Access-Control-Allow-Origin: https://www.attacker.com

Access-Control-Allow-Credentials: true

这两个返回头表示应用程序允许来自任何Origin的任何脚本向应用程序发出CORS请求，这时候程序员的代码是这样写的：

d3f040530bf546b9c150132d08fd4310.png

受害者访问攻击者构造好的URL之后，成功获取用户的敏感数据。

471d2b61e69b691102f0b2f002a7fbf9.png

F12查看浏览器发出的请求，发现其带上了Cookie，成功绕过跨域的同源限制。

f41b754f4027c0466e709d530c70b6f7.png

  • 第2种情况：

服务器返回如下消息头，这种情况下，利用起来稍有困难，这里的null必须全部都是小写，漏洞仍然是高危。

Access-Control-Allow-Origin: null

Access-Control-Allow-Credentials: true

在这种情况下，应用程序HTTP响应头Access-Control-Allow-Origin的值始终为null。当用户指定null以外的任何值时，应用程序不会处理。

0a5e48c4e3531467c8c7e6d65585a84d.png

这时候访问http://192.168.237.199/attack.html，发现浏览器提示CORS策略错误。

8999a82d4563af197efd92b89100b0d8.png

因为这时候的Origin不等于null

2730e3efbd8495b5b7ebae5ef730bb20.png

这里需要想办法让Origin等于null，于是攻击者构造如下js代码：

d64a9528769681870d2dc5722a902e4d.png

此时发现仍然可以成功获取用户的敏感数据。

f5ee3309922f3c52bcae68e4b438e380.png

  • 第3种情况：

服务器返回如下消息头，这种情况下，其实是不存在漏洞的，如果非要牵强地说存在漏洞，可以协商CORS配置错误，毕竟设置为*本身就有问题。

Access-Control-Allow-Origin: *

Access-Control-Allow-Credentials: true

对应着java代码如下：

bbaf09c1cc39971d5c575464875e38a4.png

访问http://www.attacker111.com/attack.html发现，浏览器直接报错，看来这种情况根本不被安全策略所允许。

8b288daa7aa45a8d94b5834e2672c5f8.png

  • 第4种情况：

服务器返回如下消息头，这个就不演示了，只能说明CORS配置存在问题，但是没法获取敏感数据，漏洞评级应为中危或者低危。

Access-Control-Allow-Origin：*

  • Chrome浏览器测试结果

接下来换谷歌Chrome浏览器最新版本下测试，发现确实成功绕过了同源策略，发起了跨域请求，但是Chrome浏览器却没有为请求带上Cookie，所以漏洞利用有限。

2d0c84da10dcaa301ba15281ca93093a.png

Part4 修补建议 

1. Access-Control-Allow-Origin中指定的来源只能是受信任的站点，避免使用Access-Control-Allow-Origin: *，避免使用Access-Control-Allow-Origin: null，否则攻击者可以伪造来源请求实现跨域资源窃取。

2. 严格校验“Origin”值，校验的正则表达式一定要编写完善，避免出现绕过的情况。

3. 减少“Access-Control-Allow-Methods”所允许的请求方法。

4. 除了正确配置CORS之外，Web服务器还应继续对敏感数据进行保护，例如身份验证和会话管理等。

bbb8aa2681deeab77a6a3b66ae4af345.png

专注于网络安全技术分享，包括红队攻防、蓝队分析、渗透测试、代码审计等。每周一篇，99%原创，敬请关注

Contact me: 0day123abc#gmail.com(replace # with @)

2b098d7652ff111c910fd3616efec50c.jpeg

你是否还在寻找稳定的海外服务器提供商？创新互联www.cdcxhl.cn海外机房具备T级流量清洗系统配攻击溯源，准确流量调度确保服务器高可用性，企业级服务器适合批量采购，新人活动首月15元起，快前往官网查看详情吧

当前标题：第40篇：CORS跨域资源共享漏洞的复现、分析、利用及修复过程-创新互联
当前地址：https://www.cdcxhl.com/article28/deoejp.html

成都网站建设公司_创新互联，为您提供动态网站、商城网站、响应式网站、网站维护、网站制作、全网营销推广

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联

猜你还喜欢下面的内容

成都网站建设公司

商城网站知识

同城分类信息