JSONP劫持和CORS跨域漏洞

注:本文仅供学习参考

进入正文之前，我们先来解决个小问题，什么是跨域？
跨域：指的是浏览器不能执行其它网站的脚本，它是由浏览器的同源策略造成的，是浏览器的安全限制！
跨域常见的两种方式，分别是JSONP和CORS。(前几骈文章有介绍)

JSONP跨域
JSONP（JSON with padding），是一种利用HTML中<script></script>元素标签，远程调用json文件来实现数据传递的技术，它的特点是可以跨域读取数据。

那么为什么需要用到JSONP这样一种方式传递不同域之间的数据呢？因为同源策略，同源策略是由Netscape提出的一个著名的安全策略，现在所有支持JavaScript的浏览器都会使用这个策略。

实战
下面拿DoraBox靶场演示一下,先查看一下源码

注意这几行

if(!@$_GET['callback']){
        echo $p -> con_function('json_encode',$info);
    }else{
        $callback = htmlspecialchars($_GET['callback']);
        echo "{$callback}(" . $p -> con_function('json_encode',$info) . ")";
    }

这里首先以get形式接收到callback的值，如果callback为空，则忽略警告输出info的json格式数据；

如果callback值不为空，则对这个值做一个过滤后输出，然后后面还是输出json格式的info的值。

从这段代码我们可以看到，callback的值是可以动态输出的，如果我们现在拿到了一个以jsonp方式传输用户认证后数据的网站，我们就可以构造出一个恶意的jsonp调用页面，然后诱使用户访问我们的页面，从而达到一个截取用户信息的目的。可以理解为读取型的csrf

伪造恶意的jsonp恶意页面

模仿受害者点击页面

成功获取到信息。

JSON劫持可能存在的点：

Referer过滤不严谨；
空Referer(在通过跨协议调用JS时，发送的http请求里的Referer为空)；
CSRF调用json文件方式不安全，token可重复利用；
JSON输出的Content-Type及编码不符合标准(gb2312可能存在宽字节注入)；
未严格过滤callback函数名及JSON里数据的输出；
未严格限制JSONP输出callback函数名的长度。

修复建议

对refer进行限制；
打乱响应主体内容；
使用严谨的token；

CORS跨域

CORS（Cross-Origin Resource Sharing 跨来源资源共享）,CORS允许浏览器向跨域服务器发出XmlHttpRequest请求，CORS与JSONP的区别：是JSONP的升级版，JSONP只能通过get方式请求，CORS支持get和post请求。

CORS跨域原理：向header中注入Access-Control-Allow-Origin服务端过判断请求头中的参数是否被允许的域来决定请求源是否有权限获取数据。

实战
先抓个包

这个响应头表示访问允许，*符号表示所有的请求源的所有形式的请求，都被允许访问数据，这样也就造成了一个跨域读取敏感信息的漏洞。

改为百度成功,假如我改成自己服务器上的话,是不是在本机就能读取到别人的敏感信息呢?

构造恶意代码

模拟受害者点击

成功读取到敏感信息

如何快速判断是否存在cors漏洞

最好的攻击案例：

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

Access-Control-Allow-Credentials: true

可能存在利用点：

Access-Control-Allow-Origin: null

Access-Control-Allow-Credentials: true

配置失误，但是几乎无法利用：

Access-Control-Allow-Origin: *

Access-Control-Allow-Credentials: true

或者只有一个：

Access-Control-Allow-Origin: *

修复建议：
加强对access-control-allow-orign的控制；

另外提一下大平台很喜欢利用cors跨域读取资源，多多使用f12打法有奇效。总的来说jsonp劫持和cors跨域都是属于csrf漏洞的一种,需要诱骗受害者点击才能触发,就是返回信息的接口被攻击者调用了 返回了敏感数据给其他人。