平時工作過于忙碌，技術的敏感度稍顯滯后，好在隱隱感覺黑哥與小熊在群里提到的Flash 0day特性（CVE-2014-4671）具備非常大的價值，于是保存了筆記，晚上抽空斷斷續續研究了下，才意識到這個0day的價值。

原文鏈接：
http://miki.it/blog/2014/7/8/abusing-jsonp-with-rosetta-flash/

烏云昨天出了個翻譯：
http://drops.wooyun.org/tips/2554

    大家可以先對照著讀讀，理解這個0day需要一些背景知識：
    1. 了解Flash在前端安全的地位，關于這點毫不避諱地推薦閱讀我們這本書《Web前端黑客技術揭秘》第二章關于Flash安全的描述，內容很全面清晰；
    2. 了解CSRF攻擊的本質，同樣我們的書也提了；
    3. 了解JSONP，隨便百度下你就知道；

這次Flash 0day特性實際上是對Flash文件格式的一次Hack（CWS壓縮，采用的是zlib里的DEFLATE壓縮算法），這種Hack的具體實現我沒仔細理解，Hack之后的結果是Flash文件可以用ASCII碼來完全表示（且是純字母數字），這個會導致什么后果呢？

我慢慢道來：

1.

曾經我們玩瀏覽器解析Hack時都明白一個道理，如何讓瀏覽器錯誤識別文件格式，即MIME類型，比如根據文件名后綴、Content-Type響應頭、文件內容等。

題外話：這種判斷規則在不同瀏覽器的實現還存在一些差異，這種差異導致有的瀏覽器可以被攻擊成功，而有的不行。

曾經著名的UTF-7 XSS就是瀏覽器根據文件內容的頭幾個字符來判斷目標文件的編碼方式，比如開頭是：

    +/v8
    +/v9
    +/v+
    +/v/

這個簡單的缺陷導致全球重要網站紛紛中招。

2.

通過這個Flash 0day特性，結合JSONP接口，就可以把Flash文件內容（純字母數字）附加到JSONP的返回結果中（通過給JSONP的callback參數賦值），為了按照Flash格式正常解析，文件頭必須是嚴格的Flash文件內容。如果沒這個Flash 0day特性，傳給JSONP的內容就很可能包含各種特殊字符，就很可能會被JSONP的防御機制給過濾掉，就好像2012年這位大牛給出的POC：

    http://50.56.33.56/blog/?p=242

當時是沒利用這個Flash 0day特性的，當然如果JSONP沒什么防御，不要這個特性也行。可惜的是正是因為這個特性的利用，Google、Facebook等都淪陷了……因為它們的JSONP防御機制允許純字母數字的字符串出現。

通過這兩點的說明，大家明白了嗎？

防御方式可以好幾種，最Nice的是：

    在JSONP callback回來的內容之前強制加上/**/，這是JavaScript注釋符，應該不會影響正常是JSON格式的解析執行，同時又可以避免根據文件頭幾個字符來決定目標文件MIME類型的解析機制。

曾經UTF-7 XSS漏洞也采用了類似的防御機制，在返回的內容前面強制加上個空格，這個道理是一樣的：）

可惜Flash修補了這個0day特性，否則這種攻擊很快會流行起來。這是一種非常經典的跨域攻擊，我沒來得及Demo，誰有結果可以告知我一聲。

本雜談比較亂，要想理解透徹，靠大家自己啃了。

最后，為什么說是0day特性，而不說是漏洞，這又是個很長的話題了……