Learning and analysis of CORS vulnerability

Homology strategy

The same source policy ( Same, Origin Policy ) is a convention, a very important safety measure is the most basic security feature that disables script from different sources to read or modify the current page, thus limiting cross-domain Access or even modify resources to prevent the occurrence of extremely bad situations where page A can freely change information on page B.

　　The same did what restrictions source strategy? How can it be considered cross-domain, with different sources?

Take http://www.a.com as an example:

*normal situation*	*http://www.a.com*	*allow*
*Different domain names*	*http://www.b.com*	*Not allowed*
*Different agreements*	*https://www.a.com*	*Not allowed*
*Different ports*	*http://www.a.com:10*	*Not allowed*
*Different subdomains*	*http://bp.a.com*	*Not allowed*

　　Value noteworthy are: homologous strategy is implemented in the browser so it can not stop sending requests and responses, when the cross-domain requests to initiate, in fact, has received the requested resource, if we are to respond to intercept the package, you can It is found that the requested resource is already included in the response package. The browser finds cross-domain. According to the same-origin policy, the browser does not allow the requested resource to be loaded.

　　hack.com willrequest datafrom test.com

　　Hair now comply with browser-origin policy prevents the loading of resources across domains of reading, then these resources actually want to read is simply not sent or has been sent to your browser from loading of it?

　　May be in a very clearly see that the requested resource has been received, but because different browsers source is blocked.

What is CORS?

　　With the progress of the times development, technology, new demand gradually produced. People began to have the need to request resources across domains. The same-origin policy prohibiting all cross-domain requests is obviously inappropriate, but it is even more impossible to abandon the same-origin policy, allowing pages from different sources to interact is a disaster. Under such demands and contradictions, CORS came into being.

　　Cross- domain resource sharing ( Cross-Origin Resource Sharing ), referred CORS, so that some pages from different sources can be cross-domain requests resources from a particular page.

　　C ORS depends on the browser. If the browser does not support CORS, it cannot be used, but there are almost no browsers that do not support CORS.　　

　　When issuing a cross-domain request, the browser will add the field Origin: xxx in the request header to indicate the source of the cross-domain request. When the server at the other end receives the request with Origin , it will send the requested The resource is returned in the response message, and some fields beginning with Access-Control- are added to the response header. Only two of them need to be concerned:

Access-Control-Allow-Origin: its value can only be a URI of an external domain or * (only one URI or * can not be written like Access-Control-Allow-Origin: http: //a.com,http: //b.com like this, although it is very convenient, but it is not allowed, only one URI is allowed after this field, the following will say a method of setting multiple domains that allow cross-site) , this value it is to allow cross-domain requests source, after receiving a response to the browser than on the field is not initiating the request URI origin , if it is * allow all domain name requests. If the two are the same, the cross-domain request is allowed, and the requested resource in the response will be loaded on the browser.
Access-Control-Allow-Credentials: The value of this field can only be true, then the received data contains cookies, and if this field is not set, cookies are not sent.

　　As this, by CORS, it can be achieved between the cross-domain access to several specific domains.

CORS settings:

　　Repair change it hosts, simulate two different sites:

192.168.10.103 www.test.com
192.168.10.103 www.hack.com

　　Press according to their own situation modified ip,

If the cross-site request is successful, success will be displayed,

The requested URL, http://www.test.com/test/test.php

<?php
echo 'success';
?>

URL to initiate cross-domain request, http://www.hack.com/test/1.html

<!DOCTYPE>
<html>
<p>Hello<p>
<script type="text/javascript">
function test()
{
    var ajax = new XMLHttpRequest();

    ajax.onreadystatechange=function()
    {
        if(ajax.readyState == 4 && ajax.status == 200)
        {
            var text = ajax.responseText;
            document.write(text)
        }
    }
    ajax.open("GET","http://www.test.com/test/test.php","true") 
    ajax.send();
}
test();
</script>
</html>

Request test.com resources on the hack.com page:

Show that cross-domain xmlhttprequest requests are prohibited

<?php
header('Access-Control-Allow-Origin:http://www.hack.com');
echo 'success';
?>

Adding the Access-Control-Allow-Origin field allows the source of hack.com to request resources across sites.

Successful cross-site access.

　　When we change Access-Control-Allow-Origin to http://www.a.com :

Failed again.

Vulnerability

　　Leakage causes of the hole produced can be divided into two, their causes are out in the Access-Control-Allow-Origin on , when configured as asterisks * , the script from any of a domain name may request all the information on this page , Which is equivalent to manually disabling the same-origin policy. The reason for this is extremely unlikely, because unless it is a completely inexperienced person, no one will set it to * . Another reason is much greater than the first one. The reason is that the programmer's carelessness or negligence caused the lack of matching.

Incomplete match :

　　This kind of problem is caused when certain rules to confirm whether to initiate cross-domain requests should be allowed access to the source, matching rules have flaws, which only confirmed that a certain part of compliance with the rules must be considered a trusted source, such as:

The http://www.test.com/test/test.php change

<?php
$origin = $_SERVER['HTTP_ORIGIN'];
$pattern = '#www.a.com#';
preg_match($pattern,$origin,$match);
if ($match)
{
    header('Access-Control-Allow-Origin:'.$origin);
}
echo 'success';
?>

　　这段代码中，只要匹配到www.hack.com，并没有确认其他部分的内容就简单的判断允许跨域请求，当攻击者使用 www.a.com.hack.com 时，很容易就骗过了规则，成功发起跨域请求并接收。

　　再举个例子，当匹配规则为确认 a.com 在Origin末尾时才允许访问，显然上面一个例子中的方法不再适用，这时仍可以构造 bbbbbbba.com 这样的域名来突破限制。

　　道高一尺魔高一丈，匹配规则有很多，突破方法有更多，这里就不一一列举了。

　没有转义：

　　当用正则表达式进行匹配时，URI中存在着许多点 . 像 bp.a.com , tieba.baidu.com , www.billbill.com 小数点.这个符号在正则表达式可以代替着任意一个字符，如果想让其仅仅代表.这个符号本身而不是匹配任何一个字符的话，应当使用转义符\. ,但很多人往往总会忘记转义，如在上述的代码中就没有进行转义：

http://www.test.com/test/test.php中注意：

$pattern = '#www.a.com#';

　　当我们使用 www.aacom.com , www.wwwaaacom.com , www.wwwaa.com 在 . 的位置随意写上一个字符就可以突破限制，正确写法应该是www\.a\.com

　　当头设置了Access-Control-Allow-Credentials:true时，恰巧产生了CORS漏洞，危害会大大增加，因为向其发起跨域请求时，它会将cookie一起发送，这是及其不希望看到的，也是非常危险的，读取了页面上的一些信息有时或许无伤大雅，但读取了cookie很多时候都是非常恐怖的。

漏洞检测与利用

　　CORS漏洞会加强xss的攻击力，哪怕是反射型的xss也增加了许多可能性。

　　检测CORS的方式可以通过不断修改Origin，检测响应中的Access-Control-Allow-Origin的值是否与Origin相同，如若相同，则存在CORS漏洞，github上有一个CORS漏洞的检测工具CORScanner，当检测到CORS时，可以这样利用：

<script>
var ajax = new XMLHttpRequest();
ajax.open('GET','http://xxx','true');
ajax.onload = main;
ajax.withCredentials = true;
ajax.send()

function main(){
xxx
}

　　其中，ajax.withCredentials = true;这一段代码的作用是将Access-Control-Allow-Credentials:true设置为true以允许读取cookie，提升危害，main中写入可以读取敏感数据birucookie并将其发送给攻击者的代码，诱使受害者执行这段代码，就可以达到获取重要信息的目的。

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

　　总体来说，CORS漏洞现在看来危害并不是特别大，但是千里之堤溃于蚁穴，无论怎样的漏洞都要有足够的重视，既是对自己负责，也是对他人负责、

Learning and analysis of CORS vulnerability

Guess you like