I have an upload form created in php on my website where people are able to upload a zip file. The zip file is then extracted and all file locations are added to a database. The upload form is for people to upload pictures only, obviously, with the files being inside the zip folder I cant check what files are being uploaded until the file has been extracted. I need a piece of code which will delete all the files which aren't image formats (.png, .jpeg, etc). I'm 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创建的上传表单，人们可以上传一个zip文件。然后提取zip文件，并将所有文件位置添加到数据库中。上传表单仅供人们上传图片，显然，文件在zip文件夹中我无法检查文件被提取之前正在上传的文件。我需要一段代码来删除所有非图像格式的文件（.png，.jpeg等）。我真的很担心人们能够上传恶意的php文件，存在很大的安全风险！我还需要注意人们改变php文件的扩展，试图绕过这个安全功能。
This is the original script I used http://net.tutsplus.com/videos/screencasts/how-to-open-zip-files-with-php/
这是我使用的原始脚本http://net.tutsplus.com/videos/screencasts/how-to-open-zip-files-with-php/
This is the code which actually extracts the .zip file:
这是实际提取.zip文件的代码：
function openZip($file_to_open) {
global $target;
$zip = new ZipArchive();
$x = $zip->open($file_to_open);
if($x === true) {
$zip->extractTo($target);
$zip->close();
unlink($file_to_open);
} else {
die("There was a problem. Please try again!");
}
}
Thanks, Ben.
谢谢，本。
10 个解决方案
#1
63
Im really worried about people being able to upload malicious php files, big security risk!
我真的很担心人们能够上传恶意的php文件，安全隐患很大！
Tip of the iceberg!
冰山一角！
i also need to be aware of people changing the extensions of php files trying to get around this security feature.
我还需要注意人们改变php文件的扩展，试图绕过这个安全功能。
Generally changing the extensions will stop PHP from interpreting those files as scripts. But that's not the only problem. There are more things than ‘...php’ that can damage the server-side; ‘.htaccess’ and files with the X bit set are the obvious ones, but by no means all you have to worry about. Even ignoring the server-side stuff, there's a huge client-side problem.
通常，更改扩展将阻止PHP将这些文件解释为脚本。但这不是唯一的问题。除了'... php'之外还有更多可能会损害服务器端的东西; '.htaccess'和设置了X位的文件是显而易见的，但绝不是你必须担心的。即使忽略服务器端的东西，也存在巨大的客户端问题。
For example if someone can upload an ‘.html’ file, they can include a <script> tag in it that hijacks a third-party user's session, and deletes all their uploaded files or changes their password or something. This is a classic cross-site-scripting (XSS) attack.
例如，如果某人可以上传“.html”文件，他们可以在其中包含一个
Plus, thanks to the ‘content-sniffing’ behaviours of some browsers (primarily IE), a file that is uploaded as ‘.gif’ can actually contain malicious HTML such as this. If IE sees telltales like (but not limited to) ‘<html>’ near the start of the file it can ignore the served ‘Content-Type’ and display as HTML, resulting in XSS.
此外，由于某些浏览器（主要是IE）的“内容嗅探”行为，上传为“.gif”的文件实际上可能包含恶意HTML等。如果IE在文件开头附近看到（但不限于）''的告密者，它可以忽略所提供的'Content-Type'并显示为HTML，从而产生XSS。
Plus, it's possible to craft a file that is both a valid image your image parser will accept, and contains embedded HTML. There are various possible outcomes depending on the exact version of the user's browser and the exact format of the image file (JPEGs in particular have a very variable set of possible header formats). There are mitigations coming in IE8, but that's no use for now, and you have to wonder why they can't simply stop doing content-sniffing, you idiots MS instead of burdening us with shonky non-standard extensions to HTTP headers that should have Just Worked in the first place.
此外，还可以制作一个文件既可以是您的图像解析器可以接受的有效图像，也可以包含嵌入式HTML。根据用户浏览器的确切版本和图像文件的确切格式，有各种可能的结果（特别是JPEG具有非常可变的一组可能的标题格式）。 IE8中有缓解措施，但现在暂时没有用，你不得不想知道为什么他们不能简单地停止内容嗅探，你痴迷MS而不是给我们带来应该有的HTTP标头的非标准扩展。刚刚开始工作。
I'm falling into a rant again. I'll stop. Tactics for serving user-supplied images securely:
我再次陷入咆哮。我会停下来安全地提供用户提供的图像的策略：
1: Never store a file on your server's filesystem using a filename taken from user input. This prevents bugs as well as attacks: different filesystems have different rules about what characters are allowable where in a filename, and it's much more difficult than you might think to ‘sanitise’ filenames.
1：切勿使用从用户输入获取的文件名将文件存储在服务器的文件系统中。这可以防止错误和攻击：不同的文件系统对文件名中允许的字符有不同的规则，而且比你想象的“清理”文件名要困难得多。
Even if you took something very restrictive like “only ASCII letters”, you still have to worry about too-long, too-short, and reserved names: try to save a file with as innocuous a name as “com.txt” on a Windows server and watch your app go down. Think you know all the weird foibles of path names of every filesystem on which your app might run? Confident?
即使您采取了非常严格的限制，例如“只有ASCII字母”，您仍然需要担心太长，太短和保留的名称：尝试保存一个名称与“com.txt”无关的文件Windows服务器并观看您的应用程序。您是否知道应用程序可能运行的每个文件系统的路径名称的所有奇怪缺陷？信心？
Instead, store file details (such as name and media-type) in the database, and use the primary key as a name in your filestore (eg. “74293.dat”). You then need a way to serve them with different apparent filenames, such as a downloader script spitting the file out, a downloader script doing a web server internal redirect, or URL rewriting.
而是在数据库中存储文件详细信息（例如名称和媒体类型），并在文件存储中使用主键作为名称（例如“74293.dat”）。然后，您需要一种方法来为它们提供不同的明显文件名，例如下载文件的下载程序脚本，执行Web服务器内部重定向的下载程序脚本或URL重写。
2: Be very, very careful using ZipArchive. There have been traversal vulnerabilities in extractTo of the same sort that have affected most naive path-based ZIP extractors. In addition, you lay yourself open to attack from ZIP bombs. Best to avoid any danger of bad filenames, by stepping through each file entry in the archive (eg. using zip_read/zip_entry_*) and checking its details before manually unpacking its stream to a file with known-good name and mode flags, that you generated without the archive's help. Ignore the folder paths inside the ZIP.
2：使用ZipArchive非常非常小心。在相同类型的extractTo中存在遍历漏洞，这些漏洞影响了大多数天真的基于路径的ZIP提取器。此外，你可以接受ZIP炸弹的攻击。通过逐步浏览存档中的每个文件条目（例如使用zip_read / zip_entry_ *）并在手动将其流解压缩到具有已知良好名称和模式标志的文件之前检查其详细信息，最好避免任何文件名错误的危险在没有档案帮助的情况下生成。忽略ZIP中的文件夹路径。
3: If you can load an image file and save it back out again, especially if you process it in some way in between (such as to resize/thumbnail it, or add a watermark) you can be reasonably certain that the results will be clean. Theoretically it might be possible to make an image that targeted a particular image compressor, so that when it was compressed the results would also look like HTML, but that seems like a very difficult attack to me.
3：如果您可以加载图像文件并将其再次保存，特别是如果您以某种方式处理它（例如调整大小/缩略图或添加水印），您可以合理地确定结果将是清洁。从理论上讲，有可能制作一个针对特定图像压缩器的图像，这样当它被压缩时，结果看起来也像HTML，但这对我来说似乎是一次非常困难的攻击。
4: If you can get away with serving all your images as downloads (ie. using ‘Content-Disposition: attachment’ in a downloader script), you're probably safe. But that might be too much of an inconvenience for users. This can work in tandem with (3), though, serving smaller, processed images inline and having the original higher-quality images available as a download only.
4：如果您可以将所有图像作为下载提供（即在下载程序脚本中使用“内容处理：附件”），那么您可能会安全。但这可能给用户带来太多不便。这可以与（3）协同工作，但是，内联地提供较小的处理图像并且仅具有下载的原始高质量图像。
5: If you must serve unaltered images inline, you can remove the cross-site-scripting risk by serving them from a different domain. For example use ‘images.example.com’ for untrusted images and ‘www.example.com’ for the main site that holds all the logic. Make sure that cookies are limited to only the correct virtual host, and that the virtual hosts are set up so they cannot respond on anything but their proper names (see also: DNS rebinding attacks). This is what many webmail services do.
5：如果必须内联提供未更改的图像，则可以通过从其他域提供跨站点脚本风险来消除这些风险。例如，对于不受信任的图像使用'images.example.com'，对于包含所有逻辑的主站点使用'www.example.com'。确保cookie仅限于正确的虚拟主机，并且虚拟主机已设置为无法响应除其正确名称之外的任何内容（另请参阅：DNS重新绑定攻击）。这是许多网络邮件服务的作用。
In summary, user-submitted media content is a problem.
总之，用户提交的媒体内容是一个问题。
In summary of the summary, AAAARRRRRRRGGGGHHH.
总结，AAAARRRRRRRGGGGHHH。
ETA re comment:
ETA评论：
at the top you mentioned about 'files with the X bit set', what do you mean by that?
在顶部你提到'有X位设置的文件'，你的意思是什么？
I can't speak for ZipArchive.extractTo() as I haven't tested it, but many extractors, when asked to dump files out of an archive, will recreate [some of] the Unix file mode flags associated with each file (if the archive was created on a Unix and so actually has mode flags). This can cause you permissions problems if, say, owner read permission is missing. But it can also be a security problem if your server is CGI-enabled: an X bit can allow the file to be interpreted as a script and passed to any script interpreter listed in the hashbang on the first line.
我不能说ZipArchive.extractTo（），因为我没有测试它，但是当被要求从存档中转储文件时，许多提取器将重新创建与每个文件关联的[某些] Unix文件模式标志（如果存档是在Unix上创建的，因此实际上有模式标志）。如果缺少所有者读取权限，这可能会导致权限问题。但如果您的服务器启用了CGI，它也可能是一个安全问题：X位可以允许将文件解释为脚本并传递给第一行hashbang中列出的任何脚本解释器。
i thought .htaccess had to be in the main root directory, is this not the case?
我以为.htaccess必须在主目录中，是不是这样？
Depends how Apache is set up, in particular the AllowOverride directive. It is common for general-purpose hosts to AllowOverride on any directory.
取决于Apache的设置方式，特别是AllowOverride指令。通用主机通常在任何目录上使用AllowOverride。
what would happen if someone still uploaded a file like ../var/www/wr_dir/evil.php?
如果有人仍然上传像./var/www/wr_dir/evil.php这样的文件，会发生什么？
I would expect the leading ‘..’ would be discarded, that's what other tools that have suffered the same vulnerability have done.
我希望领先的'..'将被丢弃，这就是遭受同样漏洞的其他工具所做的。
But I still wouldn't trust extractTo() against hostile input, there are too many weird little filename/directory-tree things that can go wrong — especially if you're expecting ever to run on Windows servers. zip_read() gives you much greater control over the dearchiving process, and hence the attacker much less.
但是我仍然不会相信extractTo（）反对恶意输入，有太多奇怪的小文件名/目录树的东西可能会出错 - 特别是如果你期望在Windows服务器上运行。 zip_read（）使您可以更好地控制解密过程，因此攻击者更少。
#2
15
First you should forbid every file that doesn’t have a proper image file extension. And after that, you could use the getimagesize function to check whether the files are regular image files.
首先，您应该禁止每个没有正确图像文件扩展名的文件。之后，您可以使用getimagesize函数检查文件是否是常规图像文件。
But furthermore you should be aware that some image formats allow comments and other meta information. This could be used for malicious code such as JavaScript that some browsers will execute under certain circumstances (see Risky MIME sniffing in Internet Explorer).
但此外，您应该知道某些图像格式允许注释和其他元信息。这可以用于某些浏览器在某些情况下会执行的恶意代码（例如JavaScript）（请参阅Internet Explorer中的Risky MIME嗅探）。
#3
9
You should probably not rely just on the filename extension, then. Try passing each file through an image library to validate that its really an image, also.
那你应该不仅仅依赖于文件扩展名。尝试通过图像库传递每个文件，以验证它真的是一个图像。
#4
2
I don't see the risk in having renamed php files in your DB... As long as you're not evaluating them as PHP files (or at all, for that matter), they can't do too much harm, and since there's no .php extension the php engine won't touch them.
我没有看到在你的数据库中重命名php文件的风险......只要你没有将它们评估为PHP文件（或者根本就没有），它们就不会造成太大的伤害，并且由于没有.php扩展名，因此php引擎不会触及它们。
I guess you could also search the files for <?php...
我猜你也可以搜索文件<？php ...
Also: assume the worst about the files uploaded to your machine. Renamed the folder into which you're saving them "viruses" and treat it accordingly. Don't make it public, don't give any file launch permissions (especially the php user), etc.
另外：假设上传到您机器的文件最糟糕。重命名您要将其保存为“病毒”的文件夹并对其进行相应处理。不要公开，不要给任何文件启动权限（特别是php用户）等。
#5
2
You might also want to consider doing mime type detection with the following library:
您可能还想考虑使用以下库进行mime类型检测：
http://ca.php.net/manual/en/ref.fileinfo.php
http://ca.php.net/manual/en/ref.fileinfo.php
#6
1
Now you are relying on your harddrive space for extracting. You can check fileheaders to determine what kind of files they are. there probably libraries for that.
现在你依靠你的硬盘空间进行提取。您可以检查文件头以确定它们是什么类型的文件。可能有图书馆。
offtopic: isnt it better to let the user select couple of images instead of uploading a zip file. Better for people that don't know what zip is (yes they exist)
offtopic：不要让用户选择几个图像而不是上传一个zip文件。对于那些不知道拉链是什么的人来说更好（是的，它们存在）
#7
1
If you set php to only parse files ending with .php, then you can just rename a file from somename.php to somename.php.jpeg and you are safe.
如果你将php设置为仅解析以.php结尾的文件，那么你只需将文件从somename.php重命名为somename.php.jpeg就可以了。
If you really want to delete the files, there is a zip library available to php. You could use it to check the names and extensions of all the files inside the zip archive uploaded, and if it contains a php file, give the user an error message.
如果你真的想要删除这些文件，那么php就有一个zip库。您可以使用它来检查上传的zip存档中所有文件的名称和扩展名，如果它包含php文件，则给用户一条错误消息。
#8
1
Personally, I'd add something to the Apache config to make sure that it served PHP files as text from the location the files are uploaded to, so you're safe, and can allow other file types to be uploaded in the future.
就个人而言，我会在Apache配置中添加一些内容，以确保它从文件上传到的位置将PHP文件作为文本提供，因此您可以安全地使用，并且可以允许其他文件类型在将来上传。
#9
0
Beaware of this Passing Malicious PHP Through getimagesize()
通过getimagesize（）知道这个传递恶意PHP
inject PHP through image functions that attempt to insure that images are safe by using the getimagesize() function
通过图像函数注入PHP，尝试使用getimagesize（）函数确保图像安全
read more here http://ha.ckers.org/blog/20070604/passing-malicious-php-through-getimagesize/
在此处阅读更多信息http://ha.ckers.org/blog/20070604/passing-malicious-php-through-getimagesize/
Better for your user logo use gravatar like here used by * ;)
更好地为您的用户徽标使用*使用的gravatar;）
#10
0
Use getimagesize function. Full procedure:- 1.) Extract extension of image/uploaded file and then compare extension with allowed extension. 2.) Now create a random string for renaming uploaded file. best idea is md5(session_id().microtime()).It can not be duplicated and if your server is very fast and can process less than a microsecond than use incremented variable and add them with string. now move that file.
使用getimagesize功能。完整程序： - 1.）提取图像/上传文件的扩展名，然后将扩展名与允许的扩展名进行比较。 2.）现在创建一个随机字符串来重命名上传的文件。最好的想法是md5（session_id（）。microtime（））。它不能被复制，如果你的服务器速度非常快，并且处理时间不到一微秒，那么使用递增的变量并用字符串添加它们。现在移动该文件。
A tip Disable PHP file processing in upload directory, it will always prevent you from any server side attack and if possible add your htaccess in root directory or in httpd config file and disable htaccess files from there now it solve your maximum problems
提示在上传目录中禁用PHP文件处理，它将始终阻止您从任何服务器端攻击，如果可能的话，在根目录或httpd配置文件中添加您的htaccess并从那里禁用htaccess文件，它现在解决了您的最大问题
#1
63
Im really worried about people being able to upload malicious php files, big security risk!
我真的很担心人们能够上传恶意的php文件，安全隐患很大！
Tip of the iceberg!
冰山一角！
i also need to be aware of people changing the extensions of php files trying to get around this security feature.
我还需要注意人们改变php文件的扩展，试图绕过这个安全功能。
Generally changing the extensions will stop PHP from interpreting those files as scripts. But that's not the only problem. There are more things than ‘...php’ that can damage the server-side; ‘.htaccess’ and files with the X bit set are the obvious ones, but by no means all you have to worry about. Even ignoring the server-side stuff, there's a huge client-side problem.
通常，更改扩展将阻止PHP将这些文件解释为脚本。但这不是唯一的问题。除了'... php'之外还有更多可能会损害服务器端的东西; '.htaccess'和设置了X位的文件是显而易见的，但绝不是你必须担心的。即使忽略服务器端的东西，也存在巨大的客户端问题。
For example if someone can upload an ‘.html’ file, they can include a <script> tag in it that hijacks a third-party user's session, and deletes all their uploaded files or changes their password or something. This is a classic cross-site-scripting (XSS) attack.
例如，如果某人可以上传“.html”文件，他们可以在其中包含一个
Plus, thanks to the ‘content-sniffing’ behaviours of some browsers (primarily IE), a file that is uploaded as ‘.gif’ can actually contain malicious HTML such as this. If IE sees telltales like (but not limited to) ‘<html>’ near the start of the file it can ignore the served ‘Content-Type’ and display as HTML, resulting in XSS.
此外，由于某些浏览器（主要是IE）的“内容嗅探”行为，上传为“.gif”的文件实际上可能包含恶意HTML等。如果IE在文件开头附近看到（但不限于）''的告密者，它可以忽略所提供的'Content-Type'并显示为HTML，从而产生XSS。
Plus, it's possible to craft a file that is both a valid image your image parser will accept, and contains embedded HTML. There are various possible outcomes depending on the exact version of the user's browser and the exact format of the image file (JPEGs in particular have a very variable set of possible header formats). There are mitigations coming in IE8, but that's no use for now, and you have to wonder why they can't simply stop doing content-sniffing, you idiots MS instead of burdening us with shonky non-standard extensions to HTTP headers that should have Just Worked in the first place.
此外，还可以制作一个文件既可以是您的图像解析器可以接受的有效图像，也可以包含嵌入式HTML。根据用户浏览器的确切版本和图像文件的确切格式，有各种可能的结果（特别是JPEG具有非常可变的一组可能的标题格式）。 IE8中有缓解措施，但现在暂时没有用，你不得不想知道为什么他们不能简单地停止内容嗅探，你痴迷MS而不是给我们带来应该有的HTTP标头的非标准扩展。刚刚开始工作。
I'm falling into a rant again. I'll stop. Tactics for serving user-supplied images securely:
我再次陷入咆哮。我会停下来安全地提供用户提供的图像的策略：
1: Never store a file on your server's filesystem using a filename taken from user input. This prevents bugs as well as attacks: different filesystems have different rules about what characters are allowable where in a filename, and it's much more difficult than you might think to ‘sanitise’ filenames.
1：切勿使用从用户输入获取的文件名将文件存储在服务器的文件系统中。这可以防止错误和攻击：不同的文件系统对文件名中允许的字符有不同的规则，而且比你想象的“清理”文件名要困难得多。
Even if you took something very restrictive like “only ASCII letters”, you still have to worry about too-long, too-short, and reserved names: try to save a file with as innocuous a name as “com.txt” on a Windows server and watch your app go down. Think you know all the weird foibles of path names of every filesystem on which your app might run? Confident?
即使您采取了非常严格的限制，例如“只有ASCII字母”，您仍然需要担心太长，太短和保留的名称：尝试保存一个名称与“com.txt”无关的文件Windows服务器并观看您的应用程序。您是否知道应用程序可能运行的每个文件系统的路径名称的所有奇怪缺陷？信心？
Instead, store file details (such as name and media-type) in the database, and use the primary key as a name in your filestore (eg. “74293.dat”). You then need a way to serve them with different apparent filenames, such as a downloader script spitting the file out, a downloader script doing a web server internal redirect, or URL rewriting.
而是在数据库中存储文件详细信息（例如名称和媒体类型），并在文件存储中使用主键作为名称（例如“74293.dat”）。然后，您需要一种方法来为它们提供不同的明显文件名，例如下载文件的下载程序脚本，执行Web服务器内部重定向的下载程序脚本或URL重写。
2: Be very, very careful using ZipArchive. There have been traversal vulnerabilities in extractTo of the same sort that have affected most naive path-based ZIP extractors. In addition, you lay yourself open to attack from ZIP bombs. Best to avoid any danger of bad filenames, by stepping through each file entry in the archive (eg. using zip_read/zip_entry_*) and checking its details before manually unpacking its stream to a file with known-good name and mode flags, that you generated without the archive's help. Ignore the folder paths inside the ZIP.
2：使用ZipArchive非常非常小心。在相同类型的extractTo中存在遍历漏洞，这些漏洞影响了大多数天真的基于路径的ZIP提取器。此外，你可以接受ZIP炸弹的攻击。通过逐步浏览存档中的每个文件条目（例如使用zip_read / zip_entry_ *）并在手动将其流解压缩到具有已知良好名称和模式标志的文件之前检查其详细信息，最好避免任何文件名错误的危险在没有档案帮助的情况下生成。忽略ZIP中的文件夹路径。
3: If you can load an image file and save it back out again, especially if you process it in some way in between (such as to resize/thumbnail it, or add a watermark) you can be reasonably certain that the results will be clean. Theoretically it might be possible to make an image that targeted a particular image compressor, so that when it was compressed the results would also look like HTML, but that seems like a very difficult attack to me.
3：如果您可以加载图像文件并将其再次保存，特别是如果您以某种方式处理它（例如调整大小/缩略图或添加水印），您可以合理地确定结果将是清洁。从理论上讲，有可能制作一个针对特定图像压缩器的图像，这样当它被压缩时，结果看起来也像HTML，但这对我来说似乎是一次非常困难的攻击。
4: If you can get away with serving all your images as downloads (ie. using ‘Content-Disposition: attachment’ in a downloader script), you're probably safe. But that might be too much of an inconvenience for users. This can work in tandem with (3), though, serving smaller, processed images inline and having the original higher-quality images available as a download only.
4：如果您可以将所有图像作为下载提供（即在下载程序脚本中使用“内容处理：附件”），那么您可能会安全。但这可能给用户带来太多不便。这可以与（3）协同工作，但是，内联地提供较小的处理图像并且仅具有下载的原始高质量图像。
5: If you must serve unaltered images inline, you can remove the cross-site-scripting risk by serving them from a different domain. For example use ‘images.example.com’ for untrusted images and ‘www.example.com’ for the main site that holds all the logic. Make sure that cookies are limited to only the correct virtual host, and that the virtual hosts are set up so they cannot respond on anything but their proper names (see also: DNS rebinding attacks). This is what many webmail services do.
5：如果必须内联提供未更改的图像，则可以通过从其他域提供跨站点脚本风险来消除这些风险。例如，对于不受信任的图像使用'images.example.com'，对于包含所有逻辑的主站点使用'www.example.com'。确保cookie仅限于正确的虚拟主机，并且虚拟主机已设置为无法响应除其正确名称之外的任何内容（另请参阅：DNS重新绑定攻击）。这是许多网络邮件服务的作用。
In summary, user-submitted media content is a problem.
总之，用户提交的媒体内容是一个问题。
In summary of the summary, AAAARRRRRRRGGGGHHH.
总结，AAAARRRRRRRGGGGHHH。
ETA re comment:
ETA评论：
at the top you mentioned about 'files with the X bit set', what do you mean by that?
在顶部你提到'有X位设置的文件'，你的意思是什么？
I can't speak for ZipArchive.extractTo() as I haven't tested it, but many extractors, when asked to dump files out of an archive, will recreate [some of] the Unix file mode flags associated with each file (if the archive was created on a Unix and so actually has mode flags). This can cause you permissions problems if, say, owner read permission is missing. But it can also be a security problem if your server is CGI-enabled: an X bit can allow the file to be interpreted as a script and passed to any script interpreter listed in the hashbang on the first line.
我不能说ZipArchive.extractTo（），因为我没有测试它，但是当被要求从存档中转储文件时，许多提取器将重新创建与每个文件关联的[某些] Unix文件模式标志（如果存档是在Unix上创建的，因此实际上有模式标志）。如果缺少所有者读取权限，这可能会导致权限问题。但如果您的服务器启用了CGI，它也可能是一个安全问题：X位可以允许将文件解释为脚本并传递给第一行hashbang中列出的任何脚本解释器。
i thought .htaccess had to be in the main root directory, is this not the case?
我以为.htaccess必须在主目录中，是不是这样？
Depends how Apache is set up, in particular the AllowOverride directive. It is common for general-purpose hosts to AllowOverride on any directory.
取决于Apache的设置方式，特别是AllowOverride指令。通用主机通常在任何目录上使用AllowOverride。
what would happen if someone still uploaded a file like ../var/www/wr_dir/evil.php?
如果有人仍然上传像./var/www/wr_dir/evil.php这样的文件，会发生什么？
I would expect the leading ‘..’ would be discarded, that's what other tools that have suffered the same vulnerability have done.
我希望领先的'..'将被丢弃，这就是遭受同样漏洞的其他工具所做的。
But I still wouldn't trust extractTo() against hostile input, there are too many weird little filename/directory-tree things that can go wrong — especially if you're expecting ever to run on Windows servers. zip_read() gives you much greater control over the dearchiving process, and hence the attacker much less.
但是我仍然不会相信extractTo（）反对恶意输入，有太多奇怪的小文件名/目录树的东西可能会出错 - 特别是如果你期望在Windows服务器上运行。 zip_read（）使您可以更好地控制解密过程，因此攻击者更少。
#2
15
First you should forbid every file that doesn’t have a proper image file extension. And after that, you could use the getimagesize function to check whether the files are regular image files.
首先，您应该禁止每个没有正确图像文件扩展名的文件。之后，您可以使用getimagesize函数检查文件是否是常规图像文件。
But furthermore you should be aware that some image formats allow comments and other meta information. This could be used for malicious code such as JavaScript that some browsers will execute under certain circumstances (see Risky MIME sniffing in Internet Explorer).
但此外，您应该知道某些图像格式允许注释和其他元信息。这可以用于某些浏览器在某些情况下会执行的恶意代码（例如JavaScript）（请参阅Internet Explorer中的Risky MIME嗅探）。
#3
9
You should probably not rely just on the filename extension, then. Try passing each file through an image library to validate that its really an image, also.
那你应该不仅仅依赖于文件扩展名。尝试通过图像库传递每个文件，以验证它真的是一个图像。
#4
2
I don't see the risk in having renamed php files in your DB... As long as you're not evaluating them as PHP files (or at all, for that matter), they can't do too much harm, and since there's no .php extension the php engine won't touch them.
我没有看到在你的数据库中重命名php文件的风险......只要你没有将它们评估为PHP文件（或者根本就没有），它们就不会造成太大的伤害，并且由于没有.php扩展名，因此php引擎不会触及它们。
I guess you could also search the files for <?php...
我猜你也可以搜索文件<？php ...
Also: assume the worst about the files uploaded to your machine. Renamed the folder into which you're saving them "viruses" and treat it accordingly. Don't make it public, don't give any file launch permissions (especially the php user), etc.
另外：假设上传到您机器的文件最糟糕。重命名您要将其保存为“病毒”的文件夹并对其进行相应处理。不要公开，不要给任何文件启动权限（特别是php用户）等。
#5
2
You might also want to consider doing mime type detection with the following library:
您可能还想考虑使用以下库进行mime类型检测：
http://ca.php.net/manual/en/ref.fileinfo.php
http://ca.php.net/manual/en/ref.fileinfo.php
#6
1
Now you are relying on your harddrive space for extracting. You can check fileheaders to determine what kind of files they are. there probably libraries for that.
现在你依靠你的硬盘空间进行提取。您可以检查文件头以确定它们是什么类型的文件。可能有图书馆。
offtopic: isnt it better to let the user select couple of images instead of uploading a zip file. Better for people that don't know what zip is (yes they exist)
offtopic：不要让用户选择几个图像而不是上传一个zip文件。对于那些不知道拉链是什么的人来说更好（是的，它们存在）
#7
1
If you set php to only parse files ending with .php, then you can just rename a file from somename.php to somename.php.jpeg and you are safe.
如果你将php设置为仅解析以.php结尾的文件，那么你只需将文件从somename.php重命名为somename.php.jpeg就可以了。
If you really want to delete the files, there is a zip library available to php. You could use it to check the names and extensions of all the files inside the zip archive uploaded, and if it contains a php file, give the user an error message.
如果你真的想要删除这些文件，那么php就有一个zip库。您可以使用它来检查上传的zip存档中所有文件的名称和扩展名，如果它包含php文件，则给用户一条错误消息。
#8
1
Personally, I'd add something to the Apache config to make sure that it served PHP files as text from the location the files are uploaded to, so you're safe, and can allow other file types to be uploaded in the future.
就个人而言，我会在Apache配置中添加一些内容，以确保它从文件上传到的位置将PHP文件作为文本提供，因此您可以安全地使用，并且可以允许其他文件类型在将来上传。
#9
0
Beaware of this Passing Malicious PHP Through getimagesize()
通过getimagesize（）知道这个传递恶意PHP
inject PHP through image functions that attempt to insure that images are safe by using the getimagesize() function
通过图像函数注入PHP，尝试使用getimagesize（）函数确保图像安全
read more here http://ha.ckers.org/blog/20070604/passing-malicious-php-through-getimagesize/
在此处阅读更多信息http://ha.ckers.org/blog/20070604/passing-malicious-php-through-getimagesize/
Better for your user logo use gravatar like here used by * ;)
更好地为您的用户徽标使用*使用的gravatar;）
#10
0
Use getimagesize function. Full procedure:- 1.) Extract extension of image/uploaded file and then compare extension with allowed extension. 2.) Now create a random string for renaming uploaded file. best idea is md5(session_id().microtime()).It can not be duplicated and if your server is very fast and can process less than a microsecond than use incremented variable and add them with string. now move that file.
使用getimagesize功能。完整程序： - 1.）提取图像/上传文件的扩展名，然后将扩展名与允许的扩展名进行比较。 2.）现在创建一个随机字符串来重命名上传的文件。最好的想法是md5（session_id（）。microtime（））。它不能被复制，如果你的服务器速度非常快，并且处理时间不到一微秒，那么使用递增的变量并用字符串添加它们。现在移动该文件。
A tip Disable PHP file processing in upload directory, it will always prevent you from any server side attack and if possible add your htaccess in root directory or in httpd config file and disable htaccess files from there now it solve your maximum problems
提示在上传目录中禁用PHP文件处理，它将始终阻止您从任何服务器端攻击，如果可能的话，在根目录或httpd配置文件中添加您的htaccess并从那里禁用htaccess文件，它现在解决了您的最大问题