前言
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:本文僅討論技術,對涉事機構不做任何評價,如有誤傷,敬請理解。
原文作者：Tuuu Nya
原文鏈接：http://www.hackersb.cn/hacker/140.html