关于 JSONP
JSONP 全称是 JSON with Padding ，是基于 JSON 格式的为解决跨域请求资源而产生的解决方案。他实现的基本原理是利用了 HTML 里 元素标签，远程调用 JSON 文件来实现数据传递。如要在 a.com 域下获取存在 b.com 的 JSON 数据( getUsers.JSON ):
{"id" : "1","name" : "知道创宇"}
那么他们可以首先通过 JSONP 的“ Padding ”这个 getUsers.JSON 输出为：
callback({"id" : "1","name" : "知道创宇"});
对于实际应用过程中 callback 的名称在后台实现是动态输出的。如上面例子在 PHP 实现：
//getUsers.php
$callback = $_GET['callback'];
print $callback.'({"id" : "1","name" : "知道创宇"});';
?>
然后在 a.com 使用 进行远程调用,在 Jquery 里可以直接这样调用：
然而，安全问题一直都是伴随着业务发展而出现的，JSONP 的出现同样带来了各种各样的安全问题。本文对 JSONP 实现过程中给带来的安全攻防问题做了一些简单介绍。
一、JSON 劫持
JSON 劫持又为“ JSON Hijacking ”，最开始提出这个概念大概是在 2008 年国外有安全研究人员提到这个 JSONP 带来的风险。其实这个问题属于 CSRF（ Cross-site request forgery 跨站请求伪造）攻击范畴。当某网站听过 JSONP 的方式来快域（一般为子域）传递用户认证后的敏感信息时，攻击者可以构造恶意的 JSONP 调用页面，诱导被攻击者访问来达到截取用户敏感信息的目的。一个典型的 JSON Hijacking 攻击代码：
这个是在乌云网上报告的一个攻击例子（ WooYun-2012-11284 ）http://www.wooyun.org/bug.php?action=view&id=11284 当被攻击者在登陆 360 网站的情况下访问了该网页时，那么用户的隐私数据（如用户名，邮箱等）可能被攻击者劫持。
虽然这种攻击已经出现了好几年了，但是目前在大的门户网站都还普遍存在的，而且由于安全意识问题很多官方可能还不认为这是一个安全问题，上面提到的例子其实当时在乌云网站上 360 是忽视了的！
当然还是随着安全意识和技术水平的提高，很多甲方公司开始重视此类安全问题，开始着手研究解决方案。其中一个方案就是验证 JSON
文件调用的来源（ Referer ）。这个方案是主要利用了 src=http://www.qq.com/login.php?calback=JSON>'"> 代码里我们使用 调用 javscript 伪协议来实现空 Referer 调用 JSON 文件。 另外一种防御手段就是通过随机 token 来防御，这个技术在 qq 的网站上应用比较多，如：http://r.qzone.qq.com/cgi-bin/tfriend/friend_show_qqfriends.cgi?uin=[QQ号码]&g_tk=[随机token] 来输出 JSON ，同样这个方案也是效的，但是同样可以出现防御实现的不严谨问题。如这个 token 可以暴力。如： function _Callback(o){ alert(o.items[0].uin); } for(i=17008;i<17009;i++){ //暴力循环调用 getJSON("http://r.qzone.qq.com/cgi-bin/tfriend/friend_show_qqfriends.cgi?uin=1111111&g_tk="+i); } 当然以上的方式是单纯的针对“ JSON 劫持”本身的来展开的各种攻防战。但是在现实里，很多漏洞是配合组合来实现突破的，比如上面提到的限制 Referer+ 部署随机 token 实现都很完美，无懈可击！但是只要在该网站上出现一个 XSS 漏洞，那么利用这个 XSS 漏洞可能让你的防御体系瞬间崩溃！ 另外这里顺带提一点：以上的方法是一些通用实现“ JSON 劫持”的方法，但是现实中某些浏览器的一些特有的处理机制（如 CSS 加载，错误信息显示等），导致一些类似“ JSON 劫持”（攻击对象不一定是 JSON ）的攻击！ 二、Callback 可定义导致的安全问题 在本文开头介绍 JSON 原理的就说明了可能是为了方便前段开发调用，一般输出时都是可定义的，开头提到的 php 实现的代码：
//getUsers.php $callback = $_GET['callback']; print $callback.'({"id" : "1","name" : "知道创宇"});'; ?> 也就是这个可定义化的 callback 名输出点又导致了各种安全问题，当然严格上来说里面提到的具体数据输出也是可以利用的，只是本文重点强调的 callback 这个输出点。 1、Content-Type 与 XSS 漏洞 在早期 JSON 出现时候，大家都没有合格的编码习惯。再输出 JSON 时，没有严格定义好 Content-Type（ Content-Type: application/json ）然后加上 callback 这个输出点没有进行过滤直接导致了一个典型的 XSS 漏洞，上面演示的 getUsers.php 就存在这个问题： http://127.0.0.1/getUsers.php?callback= 对于 Content-Type 来说早期还有一部分人比较喜欢使用 application / javascript 而这个头在 IE 等浏览器下一样可以解析 HTML 导致 XSS 漏洞。对于这种类型的漏洞，防御主要是从两个点去部署的： a、严格定义 Content-Type: application / json 这样的防御机制导致了浏览器不解析恶意插入的 XSS 代码（直接访问提示文件下载）。但是凡事都有个案，在 IE 的进化过程中就出现过通过一些技巧绕过 Content-Type 防御解析 html ，比如在 IE6、7 等版本时请求的 URL 文件后面加一个 /x.html 就可以解析 html （ http://127.0.0.1/getUsers.php/x.html?callback= ） 具体参考：http://hi.baidu.com/hi_heige/item/f1ecde01c4af3ed61ef04646 b、过滤 callback 以及 JSON 数据输出 这样的防御机制是比较传统的攻防思维，对输出点进行 xss 过滤。又是一个看上去很完美的解决方案，但是往往都是“事与愿违”。当年( 2011 年)一个 utf7-BOM 就复活了 n 个 XSS 漏洞。这种攻击方式主要还是存在与 IE 里(注在 IE 较新版本里已经“修复”) 也就是当我们在 callback 点输出 +/v8 这样的 utf7-BOM 的时候， IE 浏览器会把当前执行的编码认为是 utf7 ,所以我们通过 utf7 提交的 XSS 代码会被自动解码并执行。如： http://127.0.0.1/getUsers.php?callback=%2B%2Fv8%20%2BADwAaAB0AG0APgA8AGIAbwBkAHkAPgA 8AHMAYwByAGkAcAB0AD4AYQBsAGUAcgB0ACgAMQApA DsAPAAvAHMAYwByAGkAcAB0AD4APAAvAGIAbwBkAHk APgA8AC8AaAB0AG0APg-%20 其中： %2B%2Fv8 %20%2BADwAaAB0AG0APgA8AGIAbwBkAHkAPgA8AHMAY wByAGkAcAB0AD4AYQBsAGUAcgB0ACgAMQApADsAPAAv AHMAYwByAGkAcAB0AD4APAAvAGIAbwBkAHkAPgA8AC8 AaAB0AG0APg-%20 URLdecode 为： +/v8 +ADwAaAB0AG0APgA8AGIAbwBkAHkAPgA8AHMAY wByAGkAcAB0AD4AYQBsAGUAcgB0ACgAMQApADs APAAvAHMAYwByAGkAcAB0AD4APAAvAGIAbwBkA HkAPgA8AC8AaAB0AG0APg- 其中 +/v8 为 utf7-BOM ，后面的为我们注入的 utf-7 编码后的 XSS 代码的： [参考：http://hi.baidu.com/hi_heige/item/357831ab6932239a14107346] 这次利用 utf7-BOM 的方法是一个非常有代表性的通用方法，IE 后面的升级也是做一定的防御，另外在开发者角度也给出了防御方法直接强制指定 Content-Type里的编码 ( Content-Type: application/json; charset=utf-8 ) 对于现在的浏览器上，虽然没有比较通用的技巧，但是对于开发者本事过滤的机制一样可能存在各种绕过的可能。 看来上面提到的 a 和 b 两点的防御缺一都可能出问题，那么我们使用“ a + b 方案”，也就是两者都上是不是很安全了不会出现问题了呢？一切皆有可能，我们拭目以待！ 三、其他文件格式（ Content-Type ）与 JSON 1、MHTML 与 JSONP 在 2011 年 IE 曾经出现过一个听过 mhtml 协议解析跨域的漏洞：MHTML Mime-Formatted Request Vulnerability ( CVE-2011-0096 ) https://technet.microsoft.com/library/security/ms11-026 而当时的一个常见利用就是利用 JSONP 调用机制里的 Callback 函数名输出点： Encoding%3Abase64%0D%0A%0D%0APGJvZHk%2BDQo8aWZyYW1lIGlkPWlmciBzcmM9Imh0dHA6Ly93d3cuODB2d WwuY29tLyI%2BPC9pZnJhbWU%2BDQo8c2NyaXB0Pg0KYWxlcnQoZG9jdW1lbnQuY29va2ll KTsNCmZ1bmN0aW9uIGNyb3NzY 29va2llKCl7DQppZnIgPSBpZnIuY29udGVudFdpbmRvdyA%2FIGlmci5jb250ZW50V2luZG93I DogaWZyLmNvbnRlbnREb2N1bWVudDsNCmFsZXJ0KGlmci5 kb2N1bWVudC5jb29raWUpDQp9DQpzZXRUaW1lb3V0KCJjc m9zc2Nvb2tpZSgpIiwxMDAwKTsNC jwvc2NyaXB0PjwvYm9keT4NCg%3D%3D%0D%0A--_boundary_by_mere--%0D%0A!cookie"> [详见： 《Hacking with mhtml protocol handler》http://www.80vul.com/mhtml/Hacking%20with%20mhtml%20protocol%20handler.txt] 这个点就充分利用了 callback 输出点直接输出一个 mhtml 文件格式，然后利用