您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 Code iProcess 课程 认证 咨询 工具 火云堂 讲座吧   成长之路  
会员   
 
   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
 
     
   
 订阅
  捐助
JSONP安全攻防技术
 
作者 周景平 来源 程序员杂志 火龙果软件  发布于 2015-7-16
1489 次浏览     评价:      
 
摘要:JSONP是基于JSON格式的为解决跨域请求资源而产生的解决方案。它的基本原理是利用HTML的元素标签,远程调用JSON文件来实现数据传递。本文将梳理JSONP实现过程中的安全攻防。

关于JSONP

JSONP全称是JSON with Padding,是基于JSON格式的为解决跨域请求资源而产生的解决方案。它的基本原理是利用HTML的元素标签,远程调用JSON文件来实现数据传递。如果想在a.com域下获取b.com下的JSON数据(getUsers.JSON):

那么可以首先通过JSONP的“Padding”这个getUsers.JSON输出为:

对于实际应用过程中callback的名称,后台实现是动态输出的。上面例子用PHP实现如下:

然后在a.com使用<script>进行远程调用,在jQuery中可以直接这样调用:

然而,安全问题一直伴随着业务发展,JSONP同样带来各种安全问题。本文就将梳理JSONP实现过程中的安全攻防。

JSON劫持

JSON劫持又称“JSON Hijacking”,2008年国外安全研究人员开始提到由JSONP带来的风险。这个问题属于CSRF(Cross-site request forgery跨站请求伪造)攻击范畴,当某网站通过JSONP的方式跨域(一般为子域)传递用户认证后的敏感信息时,攻击者可以构造恶意的JSONP调用页面,诱导被攻击者访问,以达到截取用户敏感信息的目的。一个典型的JSON Hijacking攻击代码如下:

这是乌云上报告的一个攻击案例(WooYun-2012-11284),当被攻击者登录360网站并访问该网页时,个人隐私数据(如用户名、邮箱等)可能被攻击者劫持。

虽然这种攻击已出现多年,但目前在大的门户网站还普遍存在,而且由于安全意识薄弱,许多企业并未意识到这一问题的重要性。

不过许多甲方公司开始重视此类安全问题,着手研究解决方案。方案之一就是验证JSON文件调用的来源(Referer)。它主要利用<script>远程加载JSON文件时会发送Referer的机制,在网站输出JSON数据时,判断Referer是否包含在白名单内。这个方法理论上可行,但具体实现过程容易出现两种逻辑问题。

【Referer过滤(正则)不严谨】

例如http://www.qq.com/login.php?calback=cb这个URL输出数据时,使用了Referer过滤。但可惜只过滤了是否包含qq.com这样的关键词,而攻击者可以通过构造URL(例如http://www.qq.com.attack.com/attack.htm或http://www.attack.com/attack.htm?qq.com)绕过Referer防御。

【空Referer】

在很多情况下,开发者部署过滤Referer来源时,忽视了空Referer的过滤。一般情况下浏览器直接访问某URL是不带Referer的,因此很多防御部署允许空Referer。恰恰由于这个疏忽,导致了整个防御系统奔溃,因为在通过跨协议调用JavaScript时,发送的HTTP请求中Referer为空。跨协议调用的一个简单例子如下:

代码中我们使用<iframe>调用JavaScript伪协议来实现空Referer调用JSON文件。

另外一种手段是通过随机token防御,这项技术在腾讯的网站上应用较多,例如通过http://r.qzone.qq.com/cgi-bin/tfriend/friend_show_qqfriends.cgi?uin=[QQ号]&g_tk=[随机token]输出JSON。这个方案是有效的,但同样存在防御实现不严谨的问题。例如此token可通过以下方式暴力破解:

当然,这些都是单纯针对“JSON劫持”本身展开的攻防战。在现实中,许多漏洞是相互配合实现突破的。例如上面提到的限制Referer+部署随机token实现都很完美,理论上无懈可击,但只要该网站存在XSS漏洞,就可能让你的防御体系瞬间崩溃!这里顺带一提,以上是一些通用实现“JSON劫持”的方法,但现实中,某些浏览器的一些特有处理机制(如CSS加载、错误信息显示等),也能引发类似“JSON劫持”(攻击对象不一定是JSON)的攻击。

callback可定义导致的安全问题

为了方便前端开发调用,输出一般都是可定义的,前文提到的PHP实现的代码:

就是因为可定义callback名输出点,导致了各种安全问题。当然严格来说,里面提到的具体数据输出也是可以利用的,只是本文重点强调callback这个输出点。

【Content-Type与XSS漏洞】

在JSON刚出现时,大多数开发者还没有良好的编码习惯。输出JSON时,没有严格定义Content-Type(Content-Type: application/json),再加上callback输出点没有进行过滤,直接导致了一个典型的XSS漏洞,上文演示的getUsers.php就存在这个问题:

对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>),具体可参考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代码会被自动解码并执行。例如:

其中:

URLdecode为:

+/v8为utf7-BOM,其后为我们注入通过utf-7编码后的XSS代码:

<htm><body><script>alert(1);

</script></body></htm>。

关于这个案例的详情可参考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

【MHTML与JSONP】

2011年,IE曾出现一个通过MHTML协议解析跨域的漏洞:MHTML Mime-Formatted Request Vulnerability(CVE-2011-0096,https://technet.microsoft.com/library/security/ms11-026)。而当时的一种常见攻击方式就是利用JSONP调用机制中的callback函数名输出点:

关于这个案例,详见《Hacking with MHTML Protocol Handler》(http://www.80vul.com/mhtml/Hacking%20with%20mhtml%20protocol%20handler.txt)。

它充分利用了callback输出点直接输出MHTML文件格式,然后利用<iframe>调用MHTML标签解析并执行HTML及JavaScript代码,这也是一个通用性的XSS漏洞(UXSS),随后微软紧急推出了解决方案及漏洞补丁程序。在微软推出安全补丁前,这个漏洞已影响Google等大型网站,当时Google为了防御这类攻击启用的措施是,在JSON输出callback时,在文件开头增加了多个换行符,让远程MHTML调用时解析失败。

在攻击角度来说,它充分利用了计算机体系的各种文件格式识别机制。在这个思维的引导下,之后还出现过多次由文件格式加载带来的安全问题,例如CSS文件格式加载导致的类“JSON劫持”,JavaScript加载及各种文件格式编码带来的安全问题等。历史进程往往会出现各种惊人的相似,JSONP与文件格式的传奇还在上演。

【FLASH与JSONP】

该来的终究会来,只是没想到相似的场景上演得这么快。就在最近的一次Flash安全更新(security bulletin APSB14-17)中修复了一个安全漏洞:

These updates include additional validation checks to ensure that Flash Player rejects malicious content from vulnerable JSONP callback APIs (CVE-2014-4671).

这个漏洞因影响了Google、Facebook、Tumblr等大网站而备受媒体关注。其攻击技术与JSONP的callback点息息相关。这个问题主要发生在HTML通过<embed>、<object>调用远程Flash文件时,会直接忽视Content-Type,而JSONP的callback输出一般都在文件开头,那么完全可以通过callback点输出一个swf的文件,然后远程HTML调用并运行swf文件。例如:

这是早在2012年就提出的通过callback输出的swf文件流,其实际效果是在被攻击的网站上存放了一个恶意swf文件,HTML远程调用这个swf文件,可直接导致CSRF攻击。

具体上传Flash文件带来的CSRF攻击,请参考《Flash+Upload Csrf攻击技术》一文(http://blog.knownsec.com/2014/06/flashupload_csrf _attacking/)。

细心的朋友可能发现,上面代码callback输出的swf文件流中存在各种特殊字符,通过前文提到的“b. 过滤callback以及JSON数据输出”方案可以直接拦截,对于Goolge、Facebook这样久经考验的大网站来说,防御不在话下。

在Flash更新“security bulletin APSB14-17”发布后,该漏洞发现者给出了漏洞细节,其中一个亮点,就是作者实现了一个纯alphanumeric输出swf文件的方法:

具体请参考http://miki.it/blog/2014/7/8/abusing-jsonp-with-rosetta-flash/。

因此,对于纯alphanumeric输出来说,那些针对XSS的过滤显然可以直接忽略,这个漏洞也证明前文我们提到的“a+b方案”能被直接绕过。

防御

通过上面的攻防对抗演练,很多开发者可能会感觉有点悲剧,各种防御机制好像都有办法绕过。这里我想到一个真理:没有绝对的安全。那么我们防御的意义在哪里呢?我认为防御的意义就是虽然没办法让程序最安全(绝对安全),但可以让它更安全。提高攻击者的技术成本和门槛是安全防御的一个主要并重要的思路。回到具体的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);这样的代码防止JavaScript远程调用。

 

   
1489 次浏览  评价: 差  订阅 捐助
 
相关文章

iOS应用安全开发,你不知道的那些事术
Web安全之SQL注入攻击
移动APP安全在渗透测试中的应用
从Google备份互联网看“数据安全”
 
相关文档

web安全设计与防护
互联网海量内容安全处理技术
黑客攻击与防范技术
WEB黑盒安全检测
 
相关课程

WEB网站与应用安全原理与实践
web应用安全架构设计
创建安全的J2EE Web应用代码
信息安全问题与防范
 

iOS应用安全开发
Web安全之SQL注入攻击
APP安全在渗透测试中的应用
初探PHP的SQL注入攻击的技术
从Google备份看“数据安全”
更多...   

WEB网站与应用安全原理与实践
web应用安全架构设计
创建安全的J2EE Web应用代码
注册信息安全专业人员(CISP)
信息安全管理
信息安全问题与防范

相关咨询服务
应用架构设计与构建


中国银行 信息安全技术及深度防御
Web应用安全架构、入侵检测与防护
某财税领域知名IT服务商 Web安全测试
普瑞克斯 web安全设计、测试与优化
北京和利时 性能和安全性测试
SUN中国工程研究院 JSF框架、安全
更多...   
 
 
 
 
 
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号