CORS跨域资源共享毛病的复现、分析、使用及修复过程

Part1 前言 

CORS跨域资源共享毛病与JSONP挟制毛病类似，都是程序员在办理跨域标题中举行了错误的设置。攻击者可以使用Web应用对用户请求数据包的Origin头校验不严格，诱骗受害者访问攻击者制作好的恶意网站，从而跨域获取受害者的敏感数据，包括转账记载、交易记载、个人身份证号信息、订单信息等等。
近几年在很多的渗透测试陈诉中，CORS跨域资源共享毛病越来越多了。有的朋友着实挖不出毛病，偶尔就会写上一个CORS跨域资源共享毛病出一份陈诉，但是细究起来以下几个标题，却都含糊其词，搞不明确。
1. 什么是CORS毛病？
2. 哪些情况下的CORS毛病是高危毛病？哪些情况下CORS毛病是没有危害的？
3. CORS毛病的怎么使用？
4. CORS毛病的修补发起？
很多朋友以为Web应用返回Access-Control-Allow-Origin: *就是存在毛病，实在这个判定是不美满的。本期作者本身写了一个Java的测试环境，给大家演示一下CORS毛病的复现过程及使用过程，信任大家一看就明确了。

Part2 CORS毛病测试结果 

首先给出终极测试结果，以下结论是自写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代码测试一下，是否可以或许获取敏感数据，大家就明确了。

• 编写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种情况：
  

首先看第1种情况，服务器返回如下消息头，这种情况下，非常好使用，以是毛病定级是高危：
Access-Control-Allow-Origin: https://www.attacker.com
Access-Control-Allow-Credentials: true
这两个返回头表示应用程序允许来自任何Origin的任何脚本向应用程序发出CORS请求，这时候程序员的代码是这样写的：

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

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

 
 

• 第2种情况：
  

服务器返回如下消息头，这种情况下，使用起来稍有困难，这里的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代码：

 

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

 

• 第3种情况：
  

服务器返回如下消息头，这种情况下，实在是不存在毛病的，假如非要牵强地说存在毛病，可以协商CORS设置错误，毕竟设置为*本身就有标题。
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
对应着java代码如下：

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

• 第4种情况：
  

服务器返回如下消息头，这个就不演示了，只能说明CORS设置存在标题，但是没法获取敏感数据，毛病评级应为中危大概低危。
Access-Control-Allow-Origin：*

• Chrome浏览器测试结果
  

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

 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服务器还应继续对敏感数据举行保护，比方身份验证和会话管理等。
 
 
 
 
 
 
 


免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。