我们允许用户上传许多文件，所有这些文件要么发送到 scribd（doc、xls、ppts 等），要么我们自己显示为视频（flowplayer 中的 flv、mov、mp4 等）。
为了避免用户上传不安全的文件，我们检查一组已知的“安全”文件扩展名，然后检查给出 MIME 类型的 file -i -b 命令的输出。
Usage: file [OPTION]... [FILE]...
Determine file type of FILEs.
...
-i, --mime output mime type strings
这是否足以保护“不安全的脚本”远离我们的服务器，还是人们使用不同的东西？
警告。如果这些文件可从您的服务器获得，那么您描述的步骤不足以保证安全。
解释。由于浏览器会在各种情况下进行内容嗅探以猜测适当的 MIME 类型，因此仍有可能发生各种微妙的跨站点脚本攻击。一般类别有时被称为内容嗅探 XSS。
请参阅以下研究论文：
以下博客文章和消息也讨论了这种威胁：
安德烈亚斯·戈尔，克里斯·史密斯。 MSIE 促进了跨站点脚本。2007 年 2 月。
杰西卡·霍普，罗旺。 SMF 上传 XSS 漏洞。2006 年 12 月。
罗伯特·麦克米兰。 一张可以窃取你 Facebook 帐户的照片。2008 年 7 月。
防御。 我建议您采用以下防御和缓解措施：
在单独的域上托管内容，该域仅用于托管用户上传的内容。这会将其沙箱化，因此内容嗅探 XSS 攻击只能攻击其他用户的内容，而不能攻击您的网站。（例如，维基百科和 Facebook 使用这种防御。）
确保Content-Type:在提供用户上传内容的每个响应上设置正确的标头。审查内容类型以确保它是安全内容类型白名单上的几个选项之一。避免发送无效的 MIME 类型（例如 , , */*），并避免缺少标头的响应；这些会受到浏览器内容类型的嗅探，因此受到攻击的风险很高。避免使用导致 IE7 进行内容类型嗅探的 MIME 类型（请参阅 Barth 等人的论文以获取列表，在表 4 中）。unknown/unknownapplication/unknownContent-Type:
提供用户提供的内容时，切勿提供可能触发执行活动代码的不安全 MIME 类型的内容。例如，避免使用以下所有内容：text/html, application/x-shockwave-flash，因为它们可能包含特权代码。不幸的是，我认为从您的网站提供用户提供的 Flash 内容并不安全。
提供用户提供的内容时，在X-Content-Type-Options: nosniff标题中包含Content-Type:标题，以禁用某些版本的 IE 上的内容类型嗅探。
对于您不希望在浏览器中显示的内容，请将其标记，以便浏览器将其作为文件下载处理：例如，添加Content-Disposition: attachment标题。
（如果这听起来很烦人，那你肯定是对的。责怪 Apache 的人包含一个糟糕的默认配置，多年来违反了 Web 标准，并且忽略了对此做些什么的请求。不幸的是，现在为时已晚：我们被卡住了拥有大量部署的浏览器，这些浏览器会做危险的事情。）
恐怕不安全。有多种攻击会诱使内容类型嗅探器相信文件是错误的内容类型。这是一个特别臭名昭著的例子：
http://adblockplus.org/blog/the-hazards-of-mime-sniffing
上一张海报的建议有利于保护您的服务器免受恶意脚本的侵害：将上传的文件移到Web 根目录之外，并编写一个脚本将它们发送给用户。您希望避免让您的 Web 服务器或运行时执行用户上传的文件。您没有指定语言，但这里有一个 PHP 示例：
http://php.net/manual/en/function.readfile.php
“文件安全”的另一个被忽视的方面是为您的用户保证文件的安全。如果您让用户下载其他用户上传的文件，则恶意用户可以使用您的网站传播恶意软件。在这种情况下，您可能希望隔离上传的文件，直到您可以使用 AV 扫描它们。
我认为这就足够了。但是，我仍然不会将上传的文件放在可以通过网络服务器直接访问的目录中：让用户通过下载脚本访问文件。这样，即使有人设法上传了可执行文件，它也不会被执行。
顺便说一句，调用“file”时要非常小心，如果用户提供的文件名是参数，请确保在 system() 中使用它之前正确转义它。