講講EXIF Viewer XSS漏洞的來龍去脈 2016-05-24

前言

2016年4月21日@補天漏洞響應平臺 爆出 @烏云網 存在存儲型XSS漏洞,那些年exif插件做過的事——烏云存儲型XSS(已被人批量打COOKIE)

3381989711

通過長圖可以看到該漏洞的最終成因是因為chrome插件Exif Viewer獲取圖片exif信息時沒有進行過濾,導致了XSS代碼的執行。

隨后,烏云官方也迅速提交了該漏洞到自己平臺(不要問我怎么知道是烏云官方自己提交的,你猜~),如圖:

并且忽略了該漏洞,并表示會對WooYun圖床上傳進行處理:

但是截至發稿前,烏云依舊沒有對圖床上傳進行處理。

當然,處理了也沒有什么卵用 :)

繼續說

本來以為這件事情就這么過去了,然而最近,國內某安全團隊利用該漏洞打到了某某某SRC審核人員的cookies,還寫了文章邀請其他安全圈子的小伙伴來討論:

我的天吶,我跟你講,當時我就是這個表情

也就不對之前所有的事情進行評價了,反正跟我也沒什么喵關系…

說重點

為什么我上面說烏云處理了圖床上傳也沒有什么卵用?

處理圖床上傳的目的是為了清除exif信息,但是要觸發xss并不需要圖片一定在該網站的圖床上

比如我們將沒有清除exif信息的圖片上傳在我們自己的服務器上,然后在目標網站上引用,一樣可以觸發..

首先上傳一張帶有xss代碼的圖片到我的網站:

可以看到是可以觸發XSS的,并且domain是我的網站。

隨后我們將這個圖片發到烏云ZONE上:

彈出的document.domain變成了zone.wooyun.org

所以 處理了圖床上傳也沒有什么卵用 :)

為什么

寫過chrome插件的人都知道,其實chrome插件就是各種js實現的,

backgroundcontent_script的什么概念我就不在這里闡述了,有興趣的小伙伴可以去某度或某歌~

我們要識別每個頁面上的圖片固然是要使用content_script,然后把match設置成http://*/*或者https://*/*

后來我看了看插件的源碼,的確是這樣:

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

就像我們進行MITM攻擊時候的代碼注入(code injection)一樣

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

補天是如何防御該漏洞的?

看到這個漏洞的時候,首先對補天漏洞響應平臺(http://butian.#)進行了測試,

當然,是不存在的 233333

因為360的圖床對exif信息進行了處理,直接清理掉了,所以還是考慮用外鏈的方式,

然后我抓包把360圖床的地址改成了我的網站地址,但是發現結果是:

我的天吶!竟然判斷圖片是不是360圖床的地址,不是的話就替換成空??!

正確的修復姿勢

我們想要正確的修復漏洞,首先應該明白漏洞的成因,

然而這個漏洞出現的原因很明顯是chrome過濾不嚴格

所以我們應該修復的問題是chrome插件,

當然,正確的使用和防范這樣的隱患也是極好的。

修復方案

首先寫一個js過濾html實體的方法:

隨后在插件識別輸出的時候進行過濾:

最終效果如圖:

最后附上Exif Viewer的fixed版本:

鏈接: http://pan.baidu.com/s/1jIEVqkQ 密碼: kixd

截止發稿前,漏洞已經通知插件官方并且將該修復版本發送給官方

等待修復吧 :)

結語

在一個安全人員的角度來看,這么一個chrome插件漏洞引起了不小的波瀾是一件好事,

這能凸顯出大家對安全的重視。

但漏洞爆出來以后,我們關注的點,應該是如何修復漏洞,而不是沒完沒了的胡扯,炒作。

ps:本文僅討論技術,對涉事機構不做任何評價,如有誤傷,敬請理解。

一级A片不卡在线观看