基于IE的MIME sniffing功能的跨站点脚本攻击

危险的MIME Sniffing：当图片藏着代码杀手

一个看似无害的操作——在网页上查看一张用户上传的图片——背后可能暗藏杀机。这源于IE浏览器一个初衷良好的特性：在将文件呈现给用户之前，它会主动检查文件的“真实”类型。这个动作，技术术语称为“MIME sniffing”或“MIME类型检测”，本意是弥补服务器可能返回错误内容类型信息的缺陷，确保更好的兼容性。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

遗憾的是，这个安全卫士的角色如今已被攻击者巧妙利用。他们可以通过精心制作一个图片文件，在其中嵌入HTML和Ja vaScript代码，从而让IE浏览器在执行“嗅探”时，误判并执行这些恶意脚本。本文将深入剖析这一风险，并为用户和网站开发者提供切实可行的防护思路。

一、危险的MIME sniffing功能

对于当下的Web 2.0应用，允许用户上传图片几乎是标配功能。但恰恰是这个看似平常的入口，为利用图片进行跨站脚本攻击打开了方便之门。大型站点通常会部署过滤器来防御恶意活动内容，但对于博客、论坛这类高度依赖用户生成内容的平台，完全禁止Ja vaScript或Flash又不太现实。

问题就出在浏览器判断文件类型的多种方式上。一般来说，有三种途径：文件扩展名（比如.jpg）、服务器HTTP头中的Content-Type（比如image/jpeg），以及文件开头的字节“签名”。然而，从IE4开始，引入了第四种方法——MIME sniffing。通俗点说，IE并不完全信任前三种标识，它会亲自检查文件开头的256个字节，以此作为最终裁决。

这个设计的初衷是双重的：一是提防服务器配置错误，二是增强兼容性。例如，即便服务器错误地将一个HTML文件声明为text/plain，IE也能“聪明”地将其识别为HTML并正确渲染。在正常情况下，如果文件扩展名、Content-Type和签名三者一致，IE就会沿用这个结果。

但麻烦在于，当这三者出现矛盾时，IE会优先采信自己“嗅探”出来的结果。攻击者正是钻了这个空子。

二、倒打一耙的MIME sniffing功能

于是，一个看似矛盾的场景出现了：一个旨在保护用户的功能，反过来成了攻击的帮凶。攻击者只需在一张图片的开头部分嵌入HTML和Ja vaScript代码，那么当IE加载这张“图片”时，它执行的就不再是显示图像，而是运行其中隐藏的恶意脚本。

这就好比收到一个包装成礼盒的冲击波，而安检系统因为相信了礼盒的外表，忽略了内部的危险。利用这种方法，攻击者可以发起跨站脚本攻击，窃取受害者在当前网站的身份验证Cookie，进而冒充受害者登录，后果可想而知。

三、援兵未至

微软早已认识到这个问题的严重性。在IE8及后续版本中，浏览器不再对图片进行MIME sniffing，从而从根本上杜绝了图片嵌入HTML代码被执行的风险。同时，服务器端也可以通过发送特定的HTTP头部（如X-Download-Options: noopen）来强制浏览器直接下载文件而非在页面上下文中打开。

然而，现实是骨感的。要让IE8及以上版本完全普及仍需时日，众多遗留系统和用户习惯意味着，在相当长一段时间内，许多Web站点仍然无法完全依赖新版浏览器的防护特性。

四、急救措施

那么，在理想的全新防护环境到来之前，我们能做些什么？实际上，有几道防线可以立即构筑。

对于用户端：其实从Windows XP SP2开始，用户就可以手动禁用IE的MIME sniffing功能。具体路径是：Internet选项 -> 安全选项卡 -> Internet区域 -> 自定义级别 -> 找到“基于内容打开文件，而不是文件扩展名”并禁用。但必须警惕的是，关闭此功能可能会重新暴露一些早已被修复的古老漏洞，这无异于拆东墙补西墙，需谨慎评估。

因此，更可靠的责任方在于网站开发与运维人员。保护访问者，确保系统不传播精心制作的恶意图像，是服务提供方的应有之义。可以采取的措施包括：

1. 一致性检查：服务器应对用户上传的文件进行严格校验。不仅检查文件扩展名，还要验证文件签名字节（在Linux下可用file命令，PHP中可用getimagesize函数）。只有两者一致，才允许文件被分发。但这方法主要针对图片格式。

2. 深度内容扫描：更彻底的方法是检查文件的前256个字节，看是否存在常见的HTML标签，如、