平时工作过于忙碌，技术的敏感度稍显滞后，好在隐隐感觉黑哥与小熊在群里提到的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特性，而不说是漏洞，这又是个很长的话题了……