php 恶意上传,阻止用户通过表单上传恶意PHP文件

Im really worried about people being able to upload malicious php files, big security risk!

冰山一角！

i also need to be aware of people changing the extensions of php files trying to get around this security feature.

通常更改扩展将阻止PHP将这些文件解释为脚本。但这不是唯一的问题。有比’… php’更多的东西可以损坏服务器端; ‘.htaccess’和X位设置的文件是显而易见的，但绝不是你所有的担心。即使忽略服务器端的东西，也有一个巨大的客户端问题。

例如，如果有人可以上传“.html”文件，则他们可以包含< script>标记，它会劫持第三方用户的会话，并删除其所有上传的文件或更改其密码或其他内容。这是一个经典的跨站点脚本(XSS)攻击。

此外，由于一些浏览器(主要是IE)的“内容嗅探”行为，上传为“.gif”的文件实际上可能包含这种恶意的HTML。如果IE在文件开头附近看到类似(但不限于)“< html>”的指示符，则它可以忽略所提供的“Content-Type”并显示为HTML，从而导致XSS。

此外，可以制作一个文件，它是图像解析器将接受的有效图像，并且包含嵌入的HTML。根据用户浏览器的确切版本以及图像文件的确切格式(特别是JPEG具有可能的报头格式的非常可变的集合)，存在各种可能的结果。在IE8有mitigations进来，但是现在没有用，你不得不想知道为什么他们不能简单地停止做内容嗅探，你惹恼了MS，而不是加重我们的HTTP标头的HTTP标头应该有刚刚工作在第一位。

我又陷入了一场咆哮。我会停下来。安全地提供用户提供的图片的策略：

1：不要使用从用户输入获取的文件名将文件存储在服务器的文件系统上。这防止错误和攻击：不同的文件系统有不同的规则，关于什么字符是允许的文件名中的哪里，并且它比你可能认为“sanitize”文件名更困难。

即使你采取了一些非常限制性的，如“只有ASCII字母”，你仍然需要担心太长，太短和保留名称：尝试保存文件作为无害的名称作为“com.txt”在Windows服务器，并观看您的应用程序下来。认为你知道你的应用程序可能运行的每个文件系统的路径名的所有古怪的foibles？信心？

相反，将文件详细信息(如名称和介质类型)存储在数据库中，并使用主键作为文件存储中的名称(例如“74293.dat”)。然后，您需要一种方法来为它们提供不同的明显文件名，例如下载脚本使文件分散，下载脚本执行Web服务器内部重定向或URL重写。

2：非常，非常小心使用ZipArchive。已经遍历vulnerabilities在extractTo的同一类，影响了大多数天真的基于路径的ZIP提取器。此外，你从ZIP bombs开始攻击。最好避免任何危险的文件名，通过逐步通过档案中的每个文件条目(例如使用zip_read/zip_entry_*)和检查其详细信息，然后手动解压缩其流到已知的文件 – 良好的名称和模式标志，您生成没有存档的帮助。忽略ZIP中的文件夹路径。

3：如果您可以加载图像文件并将其再次保存，特别是如果您以某种方式在其间进行处理(例如调整图像文件大小/缩略图或添加水印)，您可以合理地确定结果将是清洁。理论上，有可能制作一个针对特定图像压缩器的图像，所以当它被压缩时，结果也会像HTML，但这似乎是一个非常困难的攻击我。

4：如果你可以放弃以下载(即在下载脚本中使用“Content-Disposition：attachment”)来提供所有的图片，你可能是安全的。但这可能给用户带来不便。这可以与(3)一起工作，但是，以更小的，经处理的图像内联，并且具有原始的较高质量图像可用作仅下载。

5：如果您必须以内联方式提供未更改的图片，则可以通过从其他域提供跨网站脚本风险来消除这些风险。例如，对于不受信任的图片使用“images.example.com”，对于包含所有逻辑的主网站使用“www.example.com”。请确保cookie仅限于正确的虚拟主机，并且虚拟主机已设置为无法对除其正确名称以外的任何内容作出响应(另请参阅：DNS重绑定攻击)。这是许多webmail服务。

总之，用户提交的媒体内容是一个问题。

总结总结，AAAARRRRRRRGGGGHHH。

ETA重新评论：

at the top you mentioned about ‘files with the X bit set’, what do you mean by that?

我不能说ZipArchive.extractTo()，因为我没有测试它，但许多提取器，当被要求从存档中转储文件，将重建[某些]与每个文件相关联的Unix文件模式标志(if存档是在Unix上创建的，所以实际上有模式标志)。这可能会导致您的权限问题，例如，所有者读取权限丢失。但是如果您的服务器启用了CGI，它也可能是一个安全问题：X位可以允许将文件解释为脚本并传递到第一行上的hashbang中列出的任何脚本解释器。

i thought .htaccess had to be in the main root directory, is this not the case?

取决于Apache是​​如何设置的，特别是AllowOverride指令。通用主机在任何目录上都允许AllowOverride是很常见的。

what would happen if someone still uploaded a file like ../var/www/wr_dir/evil.php?

我希望领先的’..’将被丢弃，这是其他工具，遭受了同样的脆弱性已经做了。

但我仍然不会信任extractTo()对敌对的输入，有太多奇怪的小文件名/目录树的东西可能会出错 – 尤其是如果你期望永远运行在Windows服务器。 zip_read()可以更好地控制解密过程，因此攻击者更少。