web安全——JSONP跨域资源共享的安全问题
JSONP跨域
JSONP 是 JSON With Padding（填充式 JSON 或参数式 JSON）的简写。
JSONP实现跨域请求的原理：简单的说，就是动态创建<script>标签，然后利用<script>的 src 属性不受同源策略约束来跨域获取数据。
JSONP 由两部分组成：回调函数 和 数据。回调函数是用来处理服务器端返回的数据，回调函数的名字一般是在请求中指定的。而数据就是我们需要获取的数据，也就是服务器端的数据。
JSONP在不同的语言中有不同的实现方法，以下只展示在html中的简单实现过程。
JSONP的简单实现过程：
举例：如果 a.com/abc.html 想得到 b.com/1.txt 中的数据，首先在abc.html中创建一个回调函数handleResponse，用来处理服务器端返回的数据。然后在abc.html中创建一个函数 foo，该函数的功能是动态添加<script>标签，src属性向服务器发送请求，请求地址为http://b.com/1.txt。然后在服务器端的请求数据1.txt中设置这个回调函数为handleResponse，并且以JSON数据形式作为参数传递，完成回调。我们来看看代码：
a.com/abc.html的代码
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>JSONP实现跨域</title>
<script type="text/javascript">
function handleResponse(response){ //处理服务器返回的数据
console.log(response); //控制台输出
}
function foo() {
var script = document.createElement("script");
script.src = "http://192.168.31.122/1.txt"; //设置请求的链接以及处理返回数据的回调函数
document.body.insertBefore(script, document.body.firstChild);
}
</script>
</head>
<body>
<button id="btn" onclick="foo()">确定</button>
</body>
</html>
192.168.10.14/1.txt 的代码，设置回调函数，数据以JSON格式存放
handleResponse([ { "name":"xie",
"sex" :"man",
"id" : "66" },
{ "name":"xiao",
"sex" :"woman",
"id" : "88" },
{ "name":"hong",
"sex" :"woman",
"id" : "77" }]
)
然后当我们点击了 确定按钮后，console控制台就输出了从192.168.10.14/1.js 传过来的JSON格式的数据了
JSONP的优缺点
JSONP的优点是：它不像XMLHttpRequest对象实现的Ajax请求那样受到同源策略的限制；它的兼容性更好，在更加古老的浏览器中都可以运行，不需要XMLHttpRequest或ActiveX的支持；并且在请求完毕后可以通过调用callback的方式回传结果。
JSONP的缺点则是：它只支持GET请求而不支持POST等其它类型的HTTP请求；它只支持跨域HTTP请求这种情况，不能解决不同域的两个页面之间如何进行JavaScript调用的问题。
CORS和JSONP对比
CORS与JSONP相比，无疑更为先进、方便和可靠。
1、 JSONP只能实现GET请求，而CORS支持所有类型的HTTP请求。 2、 使用CORS，开发者可以使用普通的XMLHttpRequest发起请求和获得数据，比起JSONP有更好的错误处理。 3、 JSONP主要被老的浏览器支持，它们往往不支持CORS，而绝大多数现代浏览器都已经支持了CORS）。
采用jsonp跨域也存在问题：
- 使用这种方法，只要是个网站都可以拿到b.com里的数据，存在安全性问题。目前已知的有Referer校验和Token校验。
- 只能是GET，不能POST
- 可能被注入恶意代码，篡改页面内容，可以采用字符串过滤来规避此问题
JSON劫持
JSON 劫持又为“ JSON Hijacking ”，最开始提出这个概念大概是在 2008 年国外有安全研究人员提到这个 JSONP 带来的风险。其实这个问题属于 CSRF（ Cross-site request forgery 跨站请求伪造）攻击范畴。当某网站通过 JSONP 的方式来跨域（一般为子域）传递用户认证后的敏感信息时，攻击者可以构造恶意的 JSONP 调用页面，诱导被攻击者访问来达到截取用户敏感信息的目的。一个典型的 JSON Hijacking 攻击代码：
<script> function wooyun(v){ alert(v.username); } </script> <script src="http://js.login.360.cn/?o=sso&m=info&func=wooyun"></script>
这个是在乌云网上报告的一个攻击例子。当被攻击者在登陆 360 网站的情况下访问了该网页时，那么用户的隐私数据（如用户名，邮箱等）可能被攻击者劫持。
虽然这种攻击已经出现了好几年了，但是目前在大的门户网站都还普遍存在的，而且由于安全意识问题很多官方可能还不认为这是一个安全问题，上面提到的例子其实当时在乌云网站上 360 是忽视了的！
当然还是随着安全意识和技术水平的提高，很多甲方公司开始重视此类安全问题，开始着手研究解决方案。其中一个方案就是验证 JSON 文件调用的来源（ Referer ）。这个方案是主要利用了 <script> 远程加载 JSON 文件时会发送 Referer ，在网站输出 JSON 数据时判断 Referer 是不是白名单合法的就可以进行防御！这个方法是可行的，但是具体实现过程中又容易导致两种常见的逻辑问题：
1、Referer过滤（正则）不严谨
比如 http://www.qq.com/login.php?calback=cb 输出数据时,使用了 Referer 过滤。但是可惜过滤的时候只过滤了 Referer 里是否存在 qq.com 这样的关键词，那么攻击者可以听过构造 URL：http://www.qq.com.attack.com/attack.htm 或者 http://www.attack.com/attack.htm?qq.com 这样的页面来发起攻击实现绕过 Referer 防御。
2、空Referer
在很多情况下，开发者在部署过滤 Referer 来源时，忽视了一个空 Referer 的过滤。一般情况下浏览器直接访问某 URL 是不带 Referer 的，所以很多防御部署是允许空 Referer 的。恰恰也就是这个忽视，导致了整个防御的奔溃。因为在通过跨协议调用 js 时，发送的 http 请求里 Referer 为空！ 跨协议调用的一个简单例子：
<iframe src="javascript:'<script>function JSON(o){alert(o.userinfo.userid);}</script><script src=http://www.qq.com/login.php?calback=JSON></script>'"></iframe>
代码里我们使用 <iframe> 调用 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 <?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=<script>alert(/xss/)</script>
对于 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=<script>alert(/xss/)</script> ）
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%2BADwAaAB0AG0APgA8AGIAbwBkAHkAPgA8AHMAYwByAGkAcAB0AD4AYQBsAGUAcgB0ACgAMQApADsAPAAvAHMAYwByAGkAcAB0AD4APAAvAGIAbwBkAHkAPgA8AC8AaAB0AG0APg-%20
其中：
%2B%2Fv8%20%2BADwAaAB0AG0APgA8AGIAbwBkAHkAPgA8AHMAYwByAGkAcAB0AD4AYQBsAGUAcgB0ACgAMQApADsAPAAvAHMAYwByAGkAcAB0AD4APAAvAGIAbwBkAHkAPgA8AC8AaAB0AG0APg-%20
URLdecode 为：
+/v8+ADwAaAB0AG0APgA8AGIAbwBkAHkAPgA8AHMAYwByAGkAcAB0AD4AYQBsAGUAcgB0ACgAMQApADsAPAAvAHMAYwByAGkAcAB0AD4APAAvAGIAbwBkAHkAPgA8AC8AaAB0AG0APg-
其中 +/v8 为 utf7-BOM ，后面的为我们注入的 utf-7 编码后的 XSS 代码的：
<html><body><script>alert(1);</script></body></html>
这次利用 utf7-BOM 的方法是一个非常有代表性的通用方法，IE 后面的升级也是做一定的防御，另外在开发者角度也给出了防御方法直接强制指定 Content-Type里的编码 ( Content-Type: application/json; charset=utf-8 ) 对于现在的浏览器上，虽然没有比较通用的技巧，但是对于开发者本事过滤的机制一样可能存在各种绕过的可能。
JSONP漏洞的挖掘
方法一：GoogleHacking语法site:target.com inurl:?callback
方法二：浏览器-调试-搜索关键字（json/jsonp/callback）
