2011年，IE曾出现一个通过MHTML协议解析跨域的漏洞：MHTML Mime-Formatted Request Vulnerability（CVE-2011-0096，https://technet.microsoft.com/library/security/ms11-026）。而当时的一种常见攻击方式就是利用JSONP调用机制中的callback函数名输出点：

关于这个案例，详见《Hacking with MHTML Protocol Handler》（%20with%20mhtml%20protocol%20handler.txt）。

它充分利用了callback输出点直接输出MHTML文件格式，然后利用＜iframe＞调用MHTML标签解析并执行HTML及JavaScript代码，这也是一个通用性的XSS漏洞（UXSS），随后微软紧急推出了解决方案及漏洞补丁程序。在微软推出安全补丁前，这个漏洞已影响Google等大型网站，当时Google为了防御这类攻击启用的措施是，在JSON输出callback时，在文件开头增加了多个换行符，让远程MHTML调用时解析失败。

在攻击角度来说，它充分利用了计算机体系的各种文件格式识别机制。在这个思维的引导下，之后还出现过多次由文件格式加载带来的安全问题，例如CSS文件格式加载导致的类“JSON劫持”，JavaScript加载及各种文件格式编码带来的安全问题等。历史进程往往会出现各种惊人的相似，JSONP与文件格式的传奇还在上演。

【FLASH与JSONP】

该来的终究会来，只是没想到相似的场景上演得这么快。就在最近的一次Flash安全更新（security bulletin APSB14-17）中修复了一个安全漏洞：

These updates include additional validation checks to ensure that Flash Player rejects malicious content from vulnerable JSONP callback APIs (CVE-2014-4671).

这个漏洞因影响了Google、Facebook、Tumblr等大网站而备受媒体关注。其攻击技术与JSONP的callback点息息相关。这个问题主要发生在HTML通过＜embed＞、＜object＞调用远程Flash文件时，会直接忽视Content-Type，而JSONP的callback输出一般都在文件开头，那么完全可以通过callback点输出一个swf的文件，然后远程HTML调用并运行swf文件。例如：

这是早在2012年就提出的通过callback输出的swf文件流，其实际效果是在被攻击的网站上存放了一个恶意swf文件，HTML远程调用这个swf文件，可直接导致CSRF攻击。

具体上传Flash文件带来的CSRF攻击，请参考《Flash+Upload Csrf攻击技术》一文（ _attacking/）。

细心的朋友可能发现，上面代码callback输出的swf文件流中存在各种特殊字符，通过前文提到的“b. 过滤callback以及JSON数据输出”方案可以直接拦截，对于Goolge、Facebook这样久经考验的大网站来说，防御不在话下。

在Flash更新“security bulletin APSB14-17”发布后，该漏洞发现者给出了漏洞细节，其中一个亮点，就是作者实现了一个纯alphanumeric输出swf文件的方法：

具体请参考。

因此，对于纯alphanumeric输出来说，那些针对XSS的过滤显然可以直接忽略，这个漏洞也证明前文我们提到的“a+b方案”能被直接绕过。

防御

通过上面的攻防对抗演练，很多开发者可能会感觉有点悲剧，各种防御机制好像都有办法绕过。这里我想到一个真理：没有绝对的安全。那么我们防御的意义在哪里呢？我认为防御的意义就是虽然没办法让程序最安全（绝对安全），但可以让它更安全。提高攻击者的技术成本和门槛是安全防御的一个主要并重要的思路。回到具体的JSONP防御上，可以总结如下几点。

本文选自程序员电子版2014年8月刊，该期更多文章请查看。2000年创刊至今所有文章目录请查看程序员封面秀。欢迎订阅程序员电子版（含iPad版、Android版、PDF版）。