PHP ZipArchive 的潜在安全问题

发布于 2024-11-19 16:31:31 字数 399 浏览 1 评论 0原文

我想允许成员选择使用 zip 文件上传内容。上传后,我想使用 PHP 的 ZipArchive 类将 zip 文件内容解压缩到一个目录,然后将文件移动到我们的系统中。

但我担心潜在的安全风险,并且我在 php.net 上找不到任何文档。我想到的第一个(好吧,唯一的)风险是有人创建一个带有“../../etc/passwd”等相对路径的 zip 文件(如果他们假设我在 /tmp/somedir 中解压该文件)。

实际上,我很难在 zip 文件中创建相对路径,所以我无法测试这样的事情是否可行。我也找不到任何方法来使用 ZipArchive 提取 zip 文件的内容,并让它忽略目录(解压缩所有文件,但不要在 zip 中创建目录结构)。

谁能告诉我这种利用是否可能,和/或如何使用 ZipArchive 忽略 zip 文件中的目录结构?

I want to allow members the option of uploading content using a zip file. Once uploaded, I want to use PHP's ZipArchive class to decompress the zip file contents to a directory, and then move the files into our system.

I'm concerned about the potential security risks though, and I can't find any documentation on php.net. The first (Well, the only) risk that comes to mind, is someone creating a zip file with relative paths like "../../etc/passwd" (If they assume I decompress the file in /tmp/somedir).

I'm actually having a hard time creating a relative path in a zip file, so I can't test if such a thing would be possible. I also can't find any way to extract the contents of the zip file using ZipArchive, and have it ignore directories (Decompress all the files, but don't create the directory structure inside the zip).

Can anyone tell me if such an exploit is possible, and/or how to ignore the directory structure in a zip file using ZipArchive?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

我一直都在从未离去 2024-11-26 16:31:32

我也有同样的担忧,并查看了 PHP 5.3 源代码,我发现了这一点:

/* Clean/normlize the path and then transform any path (absolute or relative)
         to a path relative to cwd (../../mydir/foo.txt > mydir/foo.txt)
 */
virtual_file_ex(&new_state, file, NULL, CWD_EXPAND TSRMLS_CC);
path_cleaned =  php_zip_make_relative_path(new_state.cwd, new_state.cwd_length);
if(!path_cleaned) {
    return 0;
}

对我来说看起来很好。查看 PHP 并查看 ./ext/zip/php_zip.c 了解详细信息。

I had the same concerns and had a look at the PHP 5.3 source code where I found this:

/* Clean/normlize the path and then transform any path (absolute or relative)
         to a path relative to cwd (../../mydir/foo.txt > mydir/foo.txt)
 */
virtual_file_ex(&new_state, file, NULL, CWD_EXPAND TSRMLS_CC);
path_cleaned =  php_zip_make_relative_path(new_state.cwd, new_state.cwd_length);
if(!path_cleaned) {
    return 0;
}

Looks fine to me. Checkout PHP and see ./ext/zip/php_zip.c for details.

や三分注定 2024-11-26 16:31:32

您需要确保提取的内容不是由您的应用程序服务器直接提供。因此,如果某人的存档中有一个 php 文件,他无法通过您的网络服务器执行它。

另一件事是您应该确保内容安全,以免包含在用户生成的内容中。但在没有 zip 存档的情况下也应该考虑这一点。

You need to make sure that the extracted contents are not served directly by your application server. So if someone has a php file in his archive that he cant execute it via your webserver.

Another thing is you should keep things safe from being included in user generated content. But this should be considered also without having zip archives in place.

陌生 2024-11-26 16:31:32

最后,我将采用 Pekka 的解决方案,即使用命令行解压缩实用程序。它提供了忽略 zip 文件中的目录的开关。其他人指出的担忧在这里不是问题。文件解压缩后,我们将使用与常规上传相同的流程将它们添加到系统中,这意味着每个文件都会使用我们已有的安全措施进行仔细检查。

In the end I'm going with Pekka's solution, of using the command line unzip utility. It provides switches to ignore directories in the zip file. The concerns others have pointed out aren't an issue here. Once the files are unzipped, we add them to the system using the same process as our regular uploads, which means each file is scrutinized using the security measures we already have in place.

橘味果▽酱 2024-11-26 16:31:31

有趣的问题,但我敦促你以不同的方式解决这个问题。我强烈建议您在 chroot 监狱中以最低权限运行 Web 进程。假设您这样做,可能发生的最糟糕的事情是您的网站被破坏,然后您恢复备份并进行一些取证以堵塞该特定漏洞。
新的漏洞不断被发现,您将很难完全保护您的网站,遵循这些预感。最大限度地减少攻击者的沙箱确实有很大帮助。

Interesting question, but I urge you to go about this a different way. I would highly recommend you run your web process with least privileges in a chroot jail. Assuming you do that, the WORST thing that can happen is your website get's defaced, and then you restore a backup and do some forensics to plug that specific hole.
New holes are discovered constantly, you will have a very difficult time completely securing your website going after hunches like these. Minimizing the attacker's sandbox really goes a long way.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文