精华内容
下载资源
问答
  • CORS跨域资源共享漏洞

    2020-04-15 11:32:50
    同源策略(SOP)限制了应用程序之间的信息共享,并且仅允许在托管应用程序的域内共享。这有效防止了系统机密信息的泄露。但与此同时,也带来了另外的问题。随着Web应用程序和微服务使用的日益增长,出于实用目的往往...

    同源策略(SOP)限制了应用程序之间的信息共享,并且仅允许在托管应用程序的域内共享。这有效防止了系统机密信息的泄露。但与此同时,也带来了另外的问题。随着Web应用程序和微服务使用的日益增长,出于实用目的往往需要将信息从一个子域传递到另一个子域,或者在不同域之间进行传递(例如将访问令牌和会话标识符,传递给另一个应用程序)。

    为了允许跨域通信,开发人员必须使用不同的技术来绕过SOP并传递敏感信息,以至于现今也成为了一个棘手的安全问题。因此,为了在不影响应用程序安全状态的情况下实现信息共享,在HTML5中引入了跨源资源共享(CORS)。但问题也随之而来,许多人为了方便干脆直接使用默认的配置,或是由于缺乏对此的了解而导致了错误的配置。

    CORS跨域资源共享

    跨域资源共享(CORS)是一种放宽同源策略的机制,它允许浏览器向跨源服务器,发出XMLHttpRequest请求,从而克服了AJAX只能同源使用的限制,以使不同的网站可以跨域获取数据。

    我们先来简单分析一下CORS跨域获取资源的过程

    CORS定义了两种跨域请求:简单请求非简单请求。简单跨域请求就是使用设定的请求方式请求数据,而非简单跨域请求则是在使用设定的请求方式请求数据之前,先发送一个OPTIONS预检请求,验证请求源是否为服务端允许源。只有"预检"通过后才会再发送一次请求用于数据传输。

    当我们需要发送一个跨域请求的时候,浏览器会首先检查这个请求,如果它是简单跨域请求,浏览器就会立刻发送这个请求。如果它是非简单跨域请求,这时候浏览器不会马上发送这个请求,而是有一个跟服务器预检验证的过程。

    简单跨域请求

    (1) 请求方法是以下三种方法之一:
    HEAD
    GET
    POST
    (2)HTTP的头信息不超出以下几种字段:
    Accept
    Accept-Language
    Content-Language
    Last-Event-ID
    Content-Type:application/x-www-form-urlencoded、 multipart/form-data、text/plain

    只有同时满足以上两个条件时,才是简单请求,否则为非简单请求。

    浏览器判断该请求为简单请求时,会在Request Header中添加 Origin 字段,它表示我们的请求源。

    如下,简单请求头:

    在这里插入图片描述

    CORS服务端会将该字段作为跨源标志。CORS接收到此次请求后, 首先会判断Origin是否在允许源(由服务端决定)范围之内。

    如果Origin指定的源在许可范围内,即验证通过,服务端会在Response Header 添加下面几个字段

    Access-Control-Allow-Origin:该字段是必须的。它的值要么是请求时Origin字段的值,要么是一个*,表示接受任意域名的请求。
    Access-Control-Allow-Credentials:该字段可选。它的值是一个布尔值,表示是否允许发送Cookie。***默认情况下,Cookie不包括在CORS请求之中。当设置为true时,即表示服务器明确许可,Cookie可以包含在请求中,一起发给服务器。这个值也只能设为true,如果服务器不要浏览器发送Cookie,删除该字段即可 ***
    Access-Control-Expose-Headers:该字段可选。CORS请求时,XMLHttpRequest对象的getResponseHeader()方法只能拿到6个基本字段:Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma。如果想拿到其他字段,就必须在Access-Control-Expose-Headers里面指定。

    如下,CROS服务端的回应:
    在这里插入图片描述

    如果Origin指定的源不在许可范围内,即验证失败,服务器也会返回一个正常的HTTP回应。浏览器发现,这个回应的头信息中的Access-Control-Allow-Origin字段不包含访问源,就知道出错了,从而抛出同源检测异常的错误。注意,这种错误无法通过状态码识别,因为HTTP回应的状态码有可能是200。
    在这里插入图片描述
    在这里插入图片描述

    上面说到,CORS请求默认不发送Cookie和HTTP认证信息。如果要把Cookie发到服务器,一方面要服务器同意,指定Access-Control-Allow-Credentials字段。

    Access-Control-Allow-Credentials:true

    另一方面,开发者必须在AJAX请求中打开withCredentials属性

    var xhr = new XMLHttpRequest();
    xhr.withCredentials = true;

    否则,即使服务器同意浏览器发送Cookie,浏览器也不会发送。或者,服务器要求设置Cookie,浏览器也不会处理。

    但是,如果省略withCredentials设置,有的浏览器还是会一起发送Cookie。这时,可以显式关闭withCredentials

    xhr.withCredentials = false;

    需要注意的是,如果要发送Cookie,即Access-Control-Allow-Credentials:true时,Access-Control-Allow-Origin就不能设为星号,必须指定明确的、与请求网页一致的域名。同时,Cookie依然遵循同源政策,只有用服务器域名设置的Cookie才会上传,其他域名的Cookie并不会上传,且(跨源)原网页代码中的document.cookie也无法读取服务器域名下的Cookie。

    总结:简单请求只需要CORS服务端在接受到携带Origin字段的跨域请求后,在response header中添加Access-Control-Allow-Origin等字段给浏览器做同源判断。

    非简单请求

    非简单请求是那种对服务器有特殊要求的请求,比如请求方法是PUT或DELETE,或者Content-Type字段的类型是application/json。非简单请求的CORS请求,会在正式通信之前,增加一次OPTIONS方法的预检请求。
    浏览器先询问服务器,当前网页所在的域名是否在服务器的许可名单之中,以及可以使用哪些HTTP动词和头信息字段。只有得到肯定答复,浏览器才会发出正式的XMLHttpRequest请求,否则就报错。

    下面简单分析一下非简单跨域请求的过程。浏览器先发送一个OPTIONS方法的预检请求。带有如下字段:

    Origin: 在CORS中专门作为Origin信息供后端比对,表明来源域。
    Access-Control-Request-Method: 接下来请求的方法,例如PUT、DELETE等等
    Access-Control-Request-Headers: 自定义的头部,所有用setRequestHeader方法设置的头部都将会以逗号隔开的形式包含在这个头中

    然后如果服务器配置了CORS,会返回对应对的字段,具体字段含义在返回结果是一并解释。

    Access-Control-Allow-Origin: 允许进行跨域请求的域名
    Access-Control-Allow-Methods: 允许进行跨域请求的方式
    Access-Control-Allow-Headers: 允许进行跨区请求的头部

    如下,OPTIONS预检的请求与相应
    在这里插入图片描述

    然后浏览器再根据服务器的返回值判断是否发送非简单请求。然后服务器处理完请求之后,会再返回结果中加上如下控制字段:

    Access-Control-Allow-Origin: 允许跨域访问的域,可以是一个域的列表,也可以是通配符"*"。这里要注意Origin规则只对域名有效,并不会对子目录有效。即http://foo.example/subdir/ 是无效的。但是不同子域名需要分开设置,这里的规则可以参照同源策略
    Access-Control-Allow-Credentials: 是否允许请求带有验证信息
    Access-Control-Expose-Headers: 允许脚本访问的返回头,请求成功后,脚本可以在XMLHttpRequest中访问这些头的信息
    Access-Control-Max-Age: 缓存此次请求的秒数。在这个时间范围内,所有同类型的请求都将不再发送预检请求而是直接使用此次返回的头作为判断依据,非常有用,大幅优化请求次数
    Access-Control-Allow-Methods: 允许使用的请求方法,以逗号隔开
    Access-Control-Allow-Headers: 允许自定义的头部,以逗号隔开,大小写不敏感

    然后浏览器通过返回结果的这些控制字段来决定是将结果开放给客户端脚本读取还是屏蔽掉。如果服务器没有配置CORS,返回结果没有控制字段,浏览器会屏蔽脚本对返回信息的读取,并报出同源检测异常的错误!

    通过上面叙述,我们得知借助CORS我们不必关心发出的请求是否跨域,浏览器会帮我们处理这些事情,但是服务端需要支持CORS,服务端实现CORS的原理也很简单,在服务端完全可以对请求做上下文处理,已达到接口允许跨域访问的目的。

    当然,也有很多第三方的CORS插件,例如:Spring MVC 在4.2以上版本也支持了CORS配置,这样,服务端也无需自己操心了!

    CORS的安全问题

    CORS非常有用,可以共享许多内容,不过这里存在风险。因为它完全是一个盲目的协议,只是通过HTTP头来控制的。那么,CORS跨域资源共享漏洞是怎么发生的呢?由于程序员配置不当,Origin源不严格,从而造成跨域问题。

    由以上可知,网站可以通过发送以下HTTP响应头部来启用CORS:

    Access-Control-Allow-Origin: https://example.com
    

    这样的话,就可以允许指定的源(http://example.com)来跨域请求服务器端的资源,并且服务器会响应。在默认情况下,发送跨域请求时不会携带cookie或其他凭据。因此,它不能用于窃取与用户相关的敏感信息(如CSRF令牌)。不过,网站服务器可以使用以下头部来启用凭据传输:

    Access-Control-Allow-Credentials:true
    

    这样浏览器在请求数据的时候就需要带上cookie。

    实现对单个域的信任是非常容易的事情。不过,如果需要信任多个域的话,那该怎么办呢?根据相关规范的建议,只需列出相关的域,并用空格加以分隔即可,例如:

    Access-Control-Allow-Origin:http://a.example.com  http://example.com
    

    但是,没有哪个浏览器真正支持这一特性。

    于是,我们可以通过使用通配符来信任所有子域,具体方法是:

    Access-Control-Allow-Origin:  *.example.com
    

    可是有一些偷懒的程序员,将Access-Control-Allow-Origin设置为允许来自所有域*的跨域请求。

    Access-Control-Allow-Origin:*
    

    这样,所有的网站都可以对其进行跨域资源请求了,这是非常危险的。不过先别高兴的太早。其实这里在设计的时候有一个很好的限制。xmlhttprequest发送的请求需要使用 “withCredentials” 来带上Cookie,如果一个目标域设置成了允许任意域的跨域请求,这个请求又带着 Cookie 的话,这个请求是不合法的。(就是如果需要实现带 Cookie 的跨域请求,CORS服务端需要明确的配置允许来源的域,使用任意域的配置是不合法的)浏览器会屏蔽掉返回的结果。Javascript 就没法获取返回的数据了。这是CORS模型最后一道防线。假如没有这个限制的话,那么 Javascript 就可以获取返回数据中的 Cookie 和 CSRF Token,以及各种敏感数据。这个限制极大的降低了CORS的风险。

    如下,这是不允许的:

    Access-Control-Allow-Origin: * 
    Access-Control-Allow-Credentials: true
    

    这时,将在浏览器控制台中收到错误消息:当凭证标志为true时,无法在Access-Control-Allow-Origin中使用通配符(各个浏览器报错显示的不一样)。
    在这里插入图片描述

    那么,CORS的漏洞到底出现在哪里呢?

    1:CORS服务端的 Access-Control-Allow-Origin 设置为了 *,并且 Access-Control-Allow-Credentials 设置为false,这样任何网站都可以获取该服务端的任何数据了。
    2:有一些网站的Access-Control-Allow-Origin他的设置并不是固定的,而是根据用户跨域请求数据的Origin来定的。这时,不管Access-Control-Allow-Credentials 设置为了 true 还是 false。任何网站都可以发起请求,并读取对这些请求的响应。意思就是任何一个网站都可以发送跨域请求来获得CORS服务端上的数据。
    在这里插入图片描述
    在这里插入图片描述

    下面的代码是通过AJAX来跨域请求获取服务端的数据

    <html lang="en">
    <head>
        <meta charset="UTF-8">
        <title>Ajax</title>
        <script type="text/javascript">
            function foo(){
                var xmlhttp=new XMLHttpRequest();
                    var url="http://127.0.0.1/1.txt";   //要跨域访问的资源
                xmlhttp.open("POST",url,true);   
                            //xmlhttp.setRequestHeader('X-PINGOTHER','AAAA');     //自定义头部,如果这样的话,就属于非简单请求了
                            //xmlhttp.setRequestHeader('Content-Type','text/xml');   //自定义头部,如果这样的话,就属于非简单请求了
                xmlhttp.send();
                xmlhttp.onreadystatechange=function()
    {
                    if (xmlhttp.readyState==4 && xmlhttp.status==200)
                    {
                        document.getElementById("my").innerHTML=xmlhttp.responseText;
                    }
                }
            }
    </script>
    </head>
    <body>
        <button id="btn" οnclick="foo()">确定</button>
        <p id="my">hello,word!</p>
    </body>
    </html>
    

    CORS漏洞的利用

    CORS(跨域资源共享)错误配置漏洞的高级利用

    三种对CORS错误配置的利用方法

    参考文章:对五家主流网站托管服务商进行的一次渗透测试

                  HTTP访问控制(CORS)
    
                  跨域——CORS详解
    
                  跨域资源共享 CORS 详解
    
                  如何利用CORS配置错误漏洞攻击比特币交易所
    
    展开全文
  • CORS跨域资源共享(Cross-origin resource sharing),是H5提供的一种机制,WEB应用程序可以通过在HTTP增加字段来告诉浏览器,哪些不同来源的服务器是有权访问本站资源的,当不同域的请求发生时,就出现了跨域的...


    前言

    我终于回来了,最近太忙了。实习真的是累啊,这篇文章真的是鸽了很久很久,半个月前就已经起了稿,因为工作的原因,经常渗透搞攻防,熬夜冠军。趁着这个美好又充满活力的周六,把之前学习的CORS漏洞写一写。


    提示:以下是本篇文章正文内容,下面案例可供参考

    一、关于CORS跨域问题的理解

    在讲这个漏洞之前,先简单说一下起因。前段时间面试中被问到:xss如何绕过http only的限制获得cookie?后来自己查阅资料,发现有几种方法,这里简单归纳下:

    (1)CVE-2012-0053

    Apache服务器2.0-2.2版本存在个漏洞 CE-2012-0053:攻击者可通过向网站植人超大的Cookie,令其HTTP头超过Apache的LititRequestFieldSize (最大请求长度,4192字节),使得Apache返回400错误,状态页中包含了HttpOnly 保护的Cookie。

    (2)Phpinfo页面

    无论是否设置了HttpOnly 属性,phpinfoO) 函数都会输出当前请求上下文的Cookie信息。如果目标网站存在PHPINFO页面,就可以通过XMLHttpRequest请求该页面获取Cookie信息。

    (3)Flash/java

    安全团队seckb在2012年提出,通过Flash、Java 的一些API可以获取到HttpOnly Cookie,这种情况可以归结为客户端的信息泄露
    还有一种就是这个CORS跨域漏洞。

    二、cors跨域漏洞和同源策略的关系

    漏洞全称 跨域资源共享(Cross-origin resource sharing)。它是同源策略的扩展,使得不同源网站之间资源的访问更加灵活。

    同源策略规定:不同域的客户端脚本在没有明确授权的情况下,不能读写对方的资源。同源的意思即为两个站点需要满足同协议,同域名,同端口这三个条件。

    因此,假如网站的CORS策略配置不当,它就有可能带来基于跨域的攻击。
    所以归根结底,这还是一个配置不当引发的安全问题。

    三、漏洞靶场演示

    为了方便演示cors漏洞,我找到一个专门针对这个漏洞的靶场,DoraBox。

    下载地址:
    https://codeload.github.com/gh0stkey/DoraBox/zip/master.

    具体安装步骤请参考百度,回归正题:
    在这里插入图片描述               图1. DoraBox
    访问http://127.0.0.1/dorabox/csrf/userinfo.php,页面会显示当前用户的信息,如下图:
    在这里插入图片描述              图2. userinfo.php

    用BurpSuite抓包分析一下请求包(Request)和响应包(Response):
    在这里插入图片描述              图3 .Request请求头
    在这里插入图片描述              图4.Response响应头

    响应包里有两个很关键的字段:Access-Control-Allow-OriginAccess-Control-Allow-Credentials
    Access-Control-Allow-Origin字段是必须的,他的值可能是请求时Origin字段的值,也可能是一个*,表示接受任意域名请求。

    一、如果Origin指定的源,不在许可范围内,服务器会返回一个正常的HTTP回应,浏览器收到这个回应发现这个回应的头信息没有包含Access-Control-Allow-Origin字段,就知道错了,从而会抛出一个错误,被XMLHttpRequest的onerror回调函数捕获。注意这种错误无法通过状态码识别,此时HTTP回应的状态码可能是200。

    二、如果Origin指定的域名在许可范围内,服务器返回的响应会多出几个头信息字段,就类似于图4。

    Access-Control-Allow-Origin:这个字段是请求时Origin字段的值,也有时候是 * ,也就是接收任意域名的请求,这个是危险的。
    Access-Control-Allow-Headers:这个字段是一个逗号分割的字符串,表明服务器支持的所有头信息字段。
    Access-Control-Allow-Credentials:值类型是布尔型,表示是否允许发送Cookie。默认情况下Cookie不包括在CORS请求中。当设为true时表示服务器明确许可,Cookie可以包含在请求中一起发送给服务器。

    (Tips:需要注意的是,下面两者组合的情况是默认不存在的,当Access-Control-Allow-Credentials属性设置为true时,即需要发送Cookie那么在服务器中Access-Control-Allow-Origin就不能设置成*,必须指定明确的与请求一致的域名,同时,Cookie依然遵循同源政策。
    Access-Control-Allow-Origin: *
    Access-Control-Allow-Credentials: true

    总而言之,CORS机制已经默认自动禁止了这种组合。)

    挖掘CORS漏洞的思路就是,可以测试下带有Access-Control-Allow-Origin: * 字段的网站是否有CORS漏洞,用BurpSuite就行。

    四、漏洞防御方法

    不要配置"Access-Control-Allow-Origin" 为通配符 * ,而且更为重要的是,要严格效验来自请求数据包中的“Origin”的值。当收到跨域请求的时候,要检查“Origin” 的值是否是一个可信的源,还要检查是否为null。
    避免使用 “Access-Control-Allow-Credentials :true”(请求中带cookie)
    减少"Access-Control-Allow-Methods"所允许的方法。

    总结

    提示:这里对文章进行总结:

    CORS,跨域资源共享(Cross-origin resource sharing),是H5提供的一种机制,WEB应用程序可以通过在HTTP增加字段来告诉浏览器,哪些不同来源的服务器是有权访问本站资源的,当不同域的请求发生时,就出现了跨域的现象。

    我也是靠着这个漏洞,加上一些七七八八的,成功拿到了漏洞盒子vulbox的漏洞证书(太好看了,有中文也有英语版本):
    在这里插入图片描述在这里插入图片描述首先第一点,这个漏洞好挖,cors漏洞我个人理解为是一个配置设置不当所导致的安全问题,也是owasp top 10中的漏洞之一。
    希望大家能清楚明白,盒子的证书虽然好看,但是实际作用不大!!!
    想要这个证书的也可以私信我,我会教你方法。

    因为个人感觉没什么技术含量在里面,所以特别好拿,仅仅是好看而已,真正体现挖洞技术的还是推荐CNVD原创漏洞证书。

    在网络安全这个圈子待很久了,认识了很多厉害的好友,我以为我能学到很多技术,可我学来学去他们只教了我一句话,有手就行。

    展开全文
  • CORS跨域资源共享漏洞验证测试

    千次阅读 2021-01-17 15:43:48
    之前在对网站进行安全性测试时,使用AWVS漏扫发现存在一个CORS跨域资源共享漏洞。记录一下验证及修复方式。 afei 漏洞等级:高危 2.CORS漏洞概述 CORS(跨源资源共享)定义了一种机制来支持客户端跨源...
    展开全文
  • 【Web漏洞】CORS跨域资源共享漏洞

    千次阅读 2020-03-12 11:11:47
    文章目录CORS跨域资源共享简单跨域请求非简单请求CORS的安全问题CORS漏洞的利用 有关于浏览器的同源策略和如何跨域获取资源,传送门 -->浏览器同源策略和跨域的实现方法 同源策略(SOP)限制了应用程序之间的信息...

    有关于浏览器的同源策略和如何跨域获取资源,传送门 -->浏览器同源策略和跨域的实现方法

    同源策略(SOP)限制了应用程序之间的信息共享,并且仅允许在托管应用程序的域内共享。这有效防止了系统机密信息的泄露。但与此同时,也带来了另外的问题。随着Web应用程序和微服务使用的日益增长,出于实用目的往往需要将信息从一个子域传递到另一个子域,或者在不同域之间进行传递(例如将访问令牌和会话标识符,传递给另一个应用程序)。

    为了允许跨域通信,开发人员必须使用不同的技术来绕过SOP并传递敏感信息,以至于现今也成为了一个棘手的安全问题。因此,为了在不影响应用程序安全状态的情况下实现信息共享,在HTML5中引入了跨源资源共享(CORS)。但问题也随之而来,许多人为了方便干脆直接使用默认的配置,或是由于缺乏对此的了解而导致了错误的配置。

    CORS跨域资源共享

    跨域资源共享(CORS)是一种放宽同源策略的机制,它允许浏览器向跨源服务器,发出XMLHttpRequest请求,从而克服了AJAX只能同源使用的限制,以使不同的网站可以跨域获取数据。

    我们先来简单分析一下CORS跨域获取资源的过程:

    CORS定义了两种跨域请求:简单请求非简单请求。简单跨域请求就是使用设定的请求方式请求数据,而非简单跨域请求则是在使用设定的请求方式请求数据之前,先发送一个OPTIONS预检请求,验证请求源是否为服务端允许源。只有"预检"通过后才会再发送一次请求用于数据传输。

    当我们需要发送一个跨域请求的时候,浏览器会首先检查这个请求,如果它是简单跨域请求,浏览器就会立刻发送这个请求。如果它是非简单跨域请求,这时候浏览器不会马上发送这个请求,而是有一个跟服务器预检验证的过程。

    简单跨域请求

    (1) 请求方法是以下三种方法之一:
     HEAD
     GET
     POST
    (2)HTTP的头信息不超出以下几种字段:
     Accept
     Accept-Language
     Content-Language
     Last-Event-ID
     Content-Type:application/x-www-form-urlencoded、 multipart/form-data、text/plain
    

    只有同时满足以上两个条件时,才是简单请求,否则为非简单请求。

    浏览器判断该请求为简单请求时,会在Request Header中添加 Origin 字段,它表示我们的请求源。

    如下,简单请求头:

    在这里插入图片描述
    CORS服务端会将该字段作为跨源标志。CORS接收到此次请求后, 首先会判断Origin是否在允许源(由服务端决定)范围之内。

    如果Origin指定的源在许可范围内,即验证通过,服务端会在Response Header 添加下面几个字段

    Access-Control-Allow-Origin:该字段是必须的。它的值要么是请求时Origin字段的值,要么是一个*,表示接受任意域名的请求。
    Access-Control-Allow-Credentials:该字段可选。它的值是一个布尔值,表示是否允许发送Cookie。默认情况下,Cookie不包括在CORS请求之中。当设置为true时,即表示服务器明确许可,Cookie可以包含在请求中,一起发给服务器。这个值也只能设为true,如果服务器不要浏览器发送Cookie,删除该字段即可
    Access-Control-Expose-Headers:该字段可选。CORS请求时,XMLHttpRequest对象的getResponseHeader()方法只能拿到6个基本字段:Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma。如果想拿到其他字段,就必须在Access-Control-Expose-Headers里面指定。
    

    如下,CROS服务端的回应:
    在这里插入图片描述
    如果Origin指定的源不在许可范围内,即验证失败,服务器也会返回一个正常的HTTP回应。浏览器发现,这个回应的头信息中的Access-Control-Allow-Origin字段不包含访问源,就知道出错了,从而抛出同源检测异常的错误。注意,这种错误无法通过状态码识别,因为HTTP回应的状态码有可能是200。
    在这里插入图片描述
    上面说到,CORS请求默认不发送Cookie和HTTP认证信息。如果要把Cookie发到服务器,一方面要服务器同意,指定Access-Control-Allow-Credentials字段。

    Access-Control-Allow-Credentials:true
    

    另一方面,开发者必须在AJAX请求中打开withCredentials属性

    var xhr = new XMLHttpRequest(); 
    xhr.withCredentials = true;
    

    否则,即使服务器同意浏览器发送Cookie,浏览器也不会发送。或者,服务器要求设置Cookie,浏览器也不会处理。

    但是,如果省略withCredentials设置,有的浏览器还是会一起发送Cookie。这时,可以显式关闭withCredentials

    xhr.withCredentials = false;
    

    需要注意的是,如果要发送Cookie,即Access-Control-Allow-Credentials:true时,Access-Control-Allow-Origin就不能设为星号,必须指定明确的、与请求网页一致的域名。同时,Cookie依然遵循同源政策,只有用服务器域名设置的Cookie才会上传,其他域名的Cookie并不会上传,且(跨源)原网页代码中的document.cookie也无法读取服务器域名下的Cookie。

    总结:简单请求只需要CORS服务端在接受到携带Origin字段的跨域请求后,在response header中添加Access-Control-Allow-Origin等字段给浏览器做同源判断。

    非简单请求

    非简单请求是那种对服务器有特殊要求的请求,比如请求方法是PUT或DELETE,或者Content-Type字段的类型是application/json。非简单请求的CORS请求,会在正式通信之前,增加一次OPTIONS方法的预检请求。
    浏览器先询问服务器,当前网页所在的域名是否在服务器的许可名单之中,以及可以使用哪些HTTP动词和头信息字段。只有得到肯定答复,浏览器才会发出正式的XMLHttpRequest请求,否则就报错。

    下面简单分析一下非简单跨域请求的过程。浏览器先发送一个OPTIONS方法的预检请求。带有如下字段:

    Origin: 在CORS中专门作为Origin信息供后端比对,表明来源域。
    Access-Control-Request-Method:  接下来请求的方法,例如PUT、DELETE等等
    Access-Control-Request-Headers: 自定义的头部,所有用setRequestHeader方法设置的头部都将会以逗号隔开的形式包含在这个头中
    

    然后如果服务器配置了CORS,会返回对应对的字段,具体字段含义在返回结果是一并解释。

    Access-Control-Allow-Origin:   允许进行跨域请求的域名
    Access-Control-Allow-Methods:  允许进行跨域请求的方式
    Access-Control-Allow-Headers:  允许进行跨区请求的头部
    

    如下,OPTIONS预检的请求与相应
    在这里插入图片描述
    然后浏览器再根据服务器的返回值判断是否发送非简单请求。然后服务器处理完请求之后,会再返回结果中加上如下控制字段:

    Access-Control-Allow-Origin: 允许跨域访问的域,可以是一个域的列表,也可以是通配符"*"。这里要注意Origin规则只对域名有效,并不会对子目录有效。即http://foo.example/subdir/ 是无效的。但是不同子域名需要分开设置,这里的规则可以参照同源策略
    Access-Control-Allow-Credentials: 是否允许请求带有验证信息
    Access-Control-Expose-Headers: 允许脚本访问的返回头,请求成功后,脚本可以在XMLHttpRequest中访问这些头的信息
    Access-Control-Max-Age: 缓存此次请求的秒数。在这个时间范围内,所有同类型的请求都将不再发送预检请求而是直接使用此次返回的头作为判断依据,非常有用,大幅优化请求次数
    Access-Control-Allow-Methods: 允许使用的请求方法,以逗号隔开
    Access-Control-Allow-Headers: 允许自定义的头部,以逗号隔开,大小写不敏感
    

    然后浏览器通过返回结果的这些控制字段来决定是将结果开放给客户端脚本读取还是屏蔽掉。如果服务器没有配置CORS,返回结果没有控制字段,浏览器会屏蔽脚本对返回信息的读取,并报出同源检测异常的错误!

    通过上面叙述,我们得知借助CORS我们不必关心发出的请求是否跨域,浏览器会帮我们处理这些事情,但是服务端需要支持CORS,服务端实现CORS的原理也很简单,在服务端完全可以对请求做上下文处理,已达到接口允许跨域访问的目的。

    当然,也有很多第三方的CORS插件,例如:Spring MVC 在4.2以上版本也支持了CORS配置,这样,服务端也无需自己操心了!

    CORS的安全问题

    CORS非常有用,可以共享许多内容,不过这里存在风险。因为它完全是一个盲目的协议,只是通过HTTP头来控制的。那么,CORS跨域资源共享漏洞是怎么发生的呢?由于程序员配置不当,Origin源不严格,从而造成跨域问题。

    由以上可知,网站可以通过发送以下HTTP响应头部来启用CORS:

    Access-Control-Allow-Origin: https://example.com
    

    这样的话,就可以允许指定的源(http://example.com)来跨域请求服务器端的资源,并且服务器会响应。在默认情况下,发送跨域请求时不会携带cookie或其他凭据。因此,它不能用于窃取与用户相关的敏感信息(如CSRF令牌)。不过,网站服务器可以使用以下头部来启用凭据传输:

    Access-Control-Allow-Credentials:true
    

    这样浏览器在请求数据的时候就需要带上cookie。

    实现对单个域的信任是非常容易的事情。不过,如果需要信任多个域的话,那该怎么办呢?根据相关规范的建议,只需列出相关的域,并用空格加以分隔即可,例如:

    Access-Control-Allow-Origin:http://a.example.com  http://example.com
    

    但是,没有哪个浏览器真正支持这一特性。

    于是,我们可以通过使用通配符来信任所有子域,具体方法是:

    Access-Control-Allow-Origin:  *.example.com
    

    可是有一些偷懒的程序员,将Access-Control-Allow-Origin设置为允许来自所有域*的跨域请求。

    Access-Control-Allow-Origin:*
    

    这样,所有的网站都可以对其进行跨域资源请求了,这是非常危险的。不过先别高兴的太早。其实这里在设计的时候有一个很好的限制。xmlhttprequest发送的请求需要使用 “withCredentials” 来带上Cookie,如果一个目标域设置成了允许任意域的跨域请求,这个请求又带着 Cookie 的话,这个请求是不合法的。(就是如果需要实现带 Cookie 的跨域请求,CORS服务端需要明确的配置允许来源的域,使用任意域的配置是不合法的)浏览器会屏蔽掉返回的结果。Javascript 就没法获取返回的数据了。这是CORS模型最后一道防线。假如没有这个限制的话,那么 Javascript 就可以获取返回数据中的 Cookie 和 CSRF Token,以及各种敏感数据。这个限制极大的降低了CORS的风险。

    如下,这是不允许的:

    Access-Control-Allow-Origin: * 
    Access-Control-Allow-Credentials: true
    

    这时,将在浏览器控制台中收到错误消息:当凭证标志为true时,无法在Access-Control-Allow-Origin中使用通配符(各个浏览器报错显示的不一样)。
    在这里插入图片描述
    那么,CORS的漏洞到底出现在哪里呢?

    1:CORS服务端的 Access-Control-Allow-Origin 设置为了 *,并且 Access-Control-Allow-Credentials 设置为false,这样任何网站都可以获取该服务端的任何数据了。
    2:有一些网站的Access-Control-Allow-Origin他的设置并不是固定的,而是根据用户跨域请求数据的Origin来定的。这时,不管Access-Control-Allow-Credentials 设置为了 true 还是 false。任何网站都可以发起请求,并读取对这些请求的响应。意思就是任何一个网站都可以发送跨域请求来获得CORS服务端上的数据。
    在这里插入图片描述
    在这里插入图片描述
    下面的代码是通过AJAX来跨域请求获取服务端的数据

    <html lang="en">
    <head>
        <meta charset="UTF-8">
        <title>Ajax</title>
        <script type="text/javascript">
            function foo(){
                var xmlhttp=new XMLHttpRequest();
                    var url="http://127.0.0.1/1.txt";   //要跨域访问的资源
                xmlhttp.open("POST",url,true);   
                            //xmlhttp.setRequestHeader('X-PINGOTHER','AAAA');     //自定义头部,如果这样的话,就属于非简单请求了
                            //xmlhttp.setRequestHeader('Content-Type','text/xml');   //自定义头部,如果这样的话,就属于非简单请求了
                xmlhttp.send();
                xmlhttp.onreadystatechange=function()
    {
                    if (xmlhttp.readyState==4 && xmlhttp.status==200)
                    {
                        document.getElementById("my").innerHTML=xmlhttp.responseText;
                    }
                }
            }
    </script>
    </head>
    <body>
        <button id="btn" οnclick="foo()">确定</button>
        <p id="my">hello,word!</p>
    </body>
    </html>
    

    CORS漏洞的利用

    CORS(跨域资源共享)错误配置漏洞的高级利用

    三种对CORS错误配置的利用方法

    参考文章:
    对五家主流网站托管服务商进行的一次渗透测试
    HTTP访问控制(CORS)
    跨域——CORS详解
    跨域资源共享 CORS 详解
    如何利用CORS配置错误漏洞攻击比特币交易所
    此文章来自此处 谢公子学安全

    展开全文
  • 跨站请求伪造(CSRF):是一种...漏洞原理:用户C访问正常网站A时进行登录,浏览器保存A的cookie;用户C再访问攻击网站B,网站B上有某个隐藏的链接或者图片标签会自动请求网站A的URL地址,例如表单提交,传指定的参数...
  • 二、CORS(跨域资源共享)简介 CORS需要浏览器和服务器同时支持。目前,所有浏览器都支持该功能,IE浏览器不能低于IE10。 整个CORS通信过程,都是浏览器自动完成,不需要用户参与。对于开发者来说,CORS通信与同源的...
  • CORS(跨域资源共享)漏洞解决方法

    千次阅读 2021-07-23 10:06:59
    最近,测试环境上的项目被360测试人员检测出来有一个CORS漏洞,以下记录下漏洞问题与解决方法。 一、低危漏洞CORS漏洞问题 测试人员访问某个url,将请求头中的Origin字段修改为任意值,结果仍然能获得正确的响应...
  • 跨域
  • 为什么会出现跨域的问题?...cors跨域资源共享,解决了前后端分离的资源共享问题。目前主流的浏览器都支持corsCORS出现场景 简答请求和非简单请求有些情况并不会触发cors的预检请求(即Options请求)我们将这种称...
  • 跨域资源共享漏洞分析总结(含实战)

    千次阅读 多人点赞 2020-04-29 14:15:19
    文章目录跨源资源共享(CORS)浏览器的同源策略概念特点主要功能跨域主要跨域请求方法JSONP跨域CORS跨域CORS的安全问题三种不安全的配置引起的安全问题通过CORS信任关系 利用XSS使用错误的CORS破坏TLS防御CORS如何预防...
  • 跨域资源共享CORS漏洞

    2021-08-22 04:11:40
    跨域资源共享 CORS 漏洞主要是由于程序员配置不当,对于 Origin 源校验不严格,从而造成跨域问题,攻击者可以利用 CORS 错误配置漏洞,从恶意网站跨域读取受害网站的敏感信息。 这里只做简单介绍,关于 CORS 漏洞的...
  • function cors() { var xhttp = new XMLHttpRequest(); xhttp.onreadystatechange = function() { if ( this .readyState == 4 && this .status == 200 ) { var a = this .responseText; document....
  • 一、项目说明 项目环境:jdk1.8+tomcat8+idea2018 源代码github地址: 实现目标:如果做过前后端分离项目的人或多或少的都会遇到过请求跨域的问题,这都是...解决跨域的方式有很多,比如jsonp、cors、if...
  • 这样便于后续的跨域资源共享漏洞的理解和运用。 同源策略(Same origin policy)是一种约定,它是浏览器最核心也最基本的安全功能,如果缺少了同源策略,则浏览器的正常功能可能都会受到影响。可以说Web是构建在...
  • CORS通信
  • 进入正文之前,我们先来解决个小问题,什么是跨域?...今天i春秋以JSONP和CORS这两个知识点,分享一篇比较基础的跨域漏洞知识点,希望能够抛砖引玉。 JSONP跨域 JSONP(JSON with padding),是一种利用...
  • 【PPT】跨域资源共享(CORS)漏洞详解-大咖聂心明-漏洞银行大咖面对面第84期
  • 目录介绍两种请求简单请求...CORS是一个W3C标准,全称是"跨域资源共享"(Cross-origin resource sharing)。 它允许浏览器向跨源服务器,发出XMLHttpRequest请求,从而克服了AJAX只能同源使用的限制。 CORS需要浏...
  • 文章目录一、什么是跨域?三、过滤器四、nginx反向代理做api转发 一、什么是跨域? 当一个请求url的协议、域名、端口三者之间任意一个与当前页面url不同即为跨域 当前页面url 被请求页面url 是否跨域 原因 ...
  • 进入正文之前,我们先来解决个小问题,什么...今天i春秋以JSONP和CORS这两个知识点,分享一篇比较基础的跨域漏洞知识点,希望能够抛砖引玉。JSONP跨域JSONP(JSON with padding),是一种利用HTML中<script>&...
  • 本文我将为大家介绍两种CORS错误配置漏洞利用的情况:第一种情况是基于XSS,第二种情况是基于高级的CORS利用技术。 注意:在开始阅读本文之前,你需要基本了解CORS是什么以及如何利用其错误配置漏洞。这里有一些很很...
  • nginx兼容跨域上传 兼容情况:各种新版本的ie10,firefox,opera,safari,chrome以及移动版safari和Android浏览器 ie9及一下版本请使用flash方式来兼容通过OPTIONS请求握手一次的方式实现跨根域发送请求,需要服务端...
  • CORS跨域漏洞的学习

    千次阅读 2019-07-27 18:07:50
    学习CORS漏洞和相关的一些知识梳理,网站如果存在这个漏洞就会有用户敏感数据被窃取的风险。 0x00 从浏览器的同源策略说起 SOP,同源策略 (Same Origin Policy),该策略是浏览器的一个安全基石,如果没有同源...
  • CORS跨域漏洞浅析

    千次阅读 2020-05-06 10:23:35
    (Cross-OriginResource Sharing,跨源资源共享) 其思想是使用自定义的HTTP头部让浏览器与服务器进行沟通。因为开发者需要进行跨域进行获取资源,应用场景,在a.com,想获取b.com中的数据,常用的2种方法进行跨域一种...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,874
精华内容 749
关键字:

cors跨域资源共享漏洞