jsonp安全

作者: 康康 分类: Web安全 发布时间: 2018-03-19 22:10

Callback 可定义导致的安全问题

 

在本文开头介绍 JSON 原理的就说明了可能是为了方便前段开发调用,一般输出时都是可定义的,开头提到的 php 实现的代码:
<?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=<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>  )

 

 

 

三、防御

通过上面的攻防对抗演练,很多开发者可能会感觉有点悲剧的味道,各种防御机制好像都有办法绕过。这里我想到一个真理:没有绝对的安全!那么我们防御的意义在哪里呢?我认为防御的意义就是虽然没办法让开发的程序最安全(绝对安全),但是可以让它更安全!提高攻击者的技术成本的门槛是安全防御的一个主要的重要的方向。我们回到具体的 JSONP 防御上可以总结如下几点:

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 远程调用。

发表评论

电子邮件地址不会被公开。 必填项已用*标注