讲讲EXIF Viewer XSS漏洞的来龙去脉 2016-05-24 #XSS #exif #chrome插件

前言

2016年4月21日@补天漏洞响应平台 爆出 @乌云网 存在存储型XSS漏洞,那些年exif插件做过的事——乌云存储型XSS（已被人批量打COOKIE）

通过长图可以看到该漏洞的最终成因是因为chrome插件Exif Viewer获取图片exif信息时没有进行过滤,导致了XSS代码的执行。

随后,乌云官方也迅速提交了该漏洞到自己平台(不要问我怎么知道是乌云官方自己提交的,你猜~),如图：

并且忽略了该漏洞，并表示会对WooYun图床上传进行处理：

但是截至发稿前,乌云依旧没有对图床上传进行处理。

当然,处理了也没有什么卵用 :)

继续说

本来以为这件事情就这么过去了,然而最近,国内某安全团队利用该漏洞打到了某某某SRC审核人员的cookies，还写了文章邀请其他安全圈子的小伙伴来讨论：

我的天呐,我跟你讲,当时我就是这个表情

也就不对之前所有的事情进行评价了,反正跟我也没什么喵关系…

说重点

为什么我上面说乌云处理了图床上传也没有什么卵用?

处理图床上传的目的是为了清除exif信息,但是要触发xss并不需要图片一定在该网站的图床上

比如我们将没有清除exif信息的图片上传在我们自己的服务器上,然后在目标网站上引用,一样可以触发..

首先上传一张带有xss代码的图片到我的网站：

可以看到是可以触发XSS的,并且domain是我的网站。

随后我们将这个图片发到乌云ZONE上：

弹出的document.domain变成了zone.wooyun.org

所以 处理了图床上传也没有什么卵用 :)

为什么

写过chrome插件的人都知道,其实chrome插件就是各种js实现的，

background和content_script的什么概念我就不在这里阐述了，有兴趣的小伙伴可以去某度或某歌~

我们要识别每个页面上的图片固然是要使用content_script，然后把match设置成http://*/*或者https://*/*

后来我看了看插件的源码,的确是这样：

然而我们知道content_script的作用是插入匹配到的页面,

就像我们进行MITM攻击时候的代码注入(code injection)一样

所以他的作用域是引用图片的域,而不是某人理解的图片所在网址的域。

补天是如何防御该漏洞的?

看到这个漏洞的时候,首先对补天漏洞响应平台(http://butian.360.cn)进行了测试,

当然，是不存在的 233333

因为360的图床对exif信息进行了处理,直接清理掉了,所以还是考虑用外链的方式,

然后我抓包把360图床的地址改成了我的网站地址,但是发现结果是：

我的天呐！竟然判断图片是不是360图床的地址,不是的话就替换成空！！

正确的修复姿势

我们想要正确的修复漏洞,首先应该明白漏洞的成因,

然而这个漏洞出现的原因很明显是chrome过滤不严格

所以我们应该修复的问题是chrome插件,

当然,正确的使用和防范这样的隐患也是极好的。

修复方案

首先写一个js过滤html实体的方法：

随后在插件识别输出的时候进行过滤：

最终效果如图：

最后附上Exif Viewer的fixed版本：

链接: http://pan.baidu.com/s/1jIEVqkQ 密码: kixd

截止发稿前,漏洞已经通知插件官方并且将该修复版本发送给官方

等待修复吧 :)

结语

在一个安全人员的角度来看,这么一个chrome插件漏洞引起了不小的波澜是一件好事,

这能凸显出大家对安全的重视。

但漏洞爆出来以后,我们关注的点,应该是如何修复漏洞,而不是没完没了的胡扯,炒作。

ps:本文仅讨论技术,对涉事机构不做任何评价,如有误伤,敬请理解。