在 PHP/Apache/Linux 环境中，为什么 chmod 777 是危险的？-解网

问：

受到这个问题讨论的启发。

我们都被教导过，将目录或文件留在基于 Linux 的虚拟主机上，权限级别为是一件坏事，并且始终根据需要设置尽可能少的权限。777

我现在很好奇利用的危险究竟在哪里，特别是在PHP / Apache上下文中。

毕竟，PHP脚本文件可以从外部执行（即通过调用Web服务器，然后调用解释器），无论它是否被标记为“可执行”，不是吗？这同样适用于通过命令行解释器调用的文件，对吧？php

那么漏洞究竟在哪里呢？是不是同一台机器上的其他用户可以访问全局可写的文件？777

php linux 安全 apache chmod

你需要软件来允许你写作。一旦你能找到一个让你写的错误（不太难），那么你就可以使用apache执行页面。如果在机器上设置了 PHP，或者 perl，...您可以将字符放在文件顶部，以告诉系统要自动运行哪个二进制文件。因此，该文件实际上是可执行的。为了获得更多乐趣，您可以先上传解释器（比如 pearl），然后上传要解释的文件（比如 ownme.pl），然后对 ownme.pl 运行 pearl。可悲的是，我是根据经验这么说的。值得庆幸的是，这不是我的代码，也没有人受伤。

2赞 Eric J. 2/26/2010

关于“属于 Serverfault”投票 - 这是 100% 的 StackOverflow 问题。这与我们编写的软件的安全性有关。

答：

6赞 Eric J. 2/26/2010 #1

它大大增加了您网站对恶意活动的脆弱性，因为只需要闯入一个帐户。

任何通过任何登录名访问您的系统的人都可以对您的页面执行任何他们想做的事情，包括将它们更改为“这个网站真的很不安全，所以请给我你的信用卡信息。

编辑：（澄清和解决评论）

许多服务器在生活中有不止一个目的。他们运行多个服务。如果您通过为每个服务分配一个唯一的用户并相应地管理文件权限来小心地将这些服务彼此隔离，是的，如果有人泄露了帐户的凭据，您仍然处于困境，但他们可以造成的损害仅限于该服务。如果您只有一个通用帐户并将整个文件系统设置为 777，则一个受损的帐户会危及计算机上的所有内容。

如果你的服务器只用于运行 Apache/PHP，并且没有其他用途，并且只有一个帐户运行 Apache/PHP，那么从应用程序的角度来看，让这个帐户遭到破坏与破坏整个机器一样好（尽管你仍然应该让系统文件受到保护，并且不能被用于运行 PHP 的帐户写入......这仍然应该只有管理员帐户/root才能实现）。

如果他们可以编写一个文件，并且它是可执行的，他们可以将其更改为在您的机器上执行的内容（可执行文件或脚本），然后使用 PHP 的shell_exec来运行该可执行文件。如果您配置为不允许shell_exec，他们也可以更改您的配置

@Pekka：如果您始终如一地应用最小访问原则，您将拥有专用于特定目的的帐户，并且将这些帐户限制为与该目的相关的文件。如果服务器的唯一目的是运行 PHP，则只有一个帐户用于此目的，其影响小于在同一机器上运行多个服务，每个服务都有一个特定的帐户，并且每个帐户都只能访问与该服务相关的文件。

0赞 Pekka 2/26/2010

@Eric J.我完全同意。我在这里的问题是关于“7”位的，因为我看到人们的（基于PHP的）网站遭到破坏，而其他人则回答说“嗯，你到处都有chmod 777，难怪你被黑客入侵了。我想具体了解一下这有什么 - 应用最少的访问是唯一的出路，这是毋庸置疑的。

32赞 Mike Sherov 2/26/2010 #2

下面是一个场景：

您有一个用户可以上载到的未受保护的目录。
他们上传两个文件：一个 shell 脚本和一个调用 shell 脚本的 php 文件。system()
他们通过访问浏览器中的 URL 来访问刚刚上传的 PHP 脚本，从而导致 shell 脚本执行。

如果这个目录是 777，这意味着任何人（包括用户 apache，这是 php 脚本将执行的格式）都可以执行它！如果未在该目录上设置执行位，并且可能未设置目录中的文件，则上述步骤 3 将不执行任何操作。

从评论中编辑：重要的不是PHP文件的权限，而是PHP文件内部的调用将由Linux用户Apache（或您设置的apache运行身份）作为linux系统调用执行，而这正是执行位的重要性所在。system()

关于系统上的任何用户都能够修改源代码，其他答案是正确的，这很糟糕。然而，更可怕的是，由于 apache 还可以修改文件，这意味着一些 Web 应用程序缺陷可能允许 Internet 上的攻击者（假设站点是公共的）拥有服务器 - 他们可以在服务器上运行自己的代码，接管您的基础设施以及您网站的任何访问者的浏览器。我可能有偏见，因为我已经看到了这种情况的发生。

2赞 testermaster 4/1/2015

你好@MikeSherov，很抱歉提出这个老问题和以下愚蠢的问题..你写了“你有一个用户可以上传到的未受保护的目录”，你说的“用户”是什么意思？如果他们没有 FTP 访问权限，他们如何在该目录中上传文件？如果我在专用服务器上，我应该没事，对吧？

3赞 Fandi Susanto 8/1/2016

嗨，@testermaster AFAIK，网页中文件上传界面的未经消毒的图像是将php文件上传到服务器的方法之一。

3赞 anshul 2/26/2010 #3

在权限方面，遵循极简主义有很多很好的一般理由，但在LAMP网络主机的上下文中，容易想到的几个是

在共享主机平台上，共享主机的其他用户现在可以读取和写入您的脚本。
On a dedicated host, rogue processes can read/write and accidentally delete your files. Let's say there is a custom logging process running in the background as user nobody which has a bug that results in it trying to . Now generally this will be harmless because there would hardly be any file that nobody should have write permissions on but this rogue process will now take your files with it.rm -rf /
To deface your website, someone needs to only gain access as any user, even say or some such dummy account. Generally, the attacker would have to do a further user level escalation attack to get to the place where he can do some damage. This is a real threat. Some non-critical services may be running under dummy accounts and might contain a vulnerability.nobody

1赞 D.Snap 1/22/2015 #4

Let's suppose you have a software package installed in your server and there is a zero day vulnerability into it, the attacker gains access to your Admin Control Panel with uploading files capabilities, if you set everything to 777 it would be trivial for him to upload a shell script anywhere he wants. However, if you set the permissions properly he can't do it since nobody/www-data/etc won't have write permissions.

上一个：clearfix 是否已弃用？

下一个：如何防止 json_encode（）删除包含无效字符的字符串

在 PHP/Apache/Linux 环境中，为什么 chmod 777 是危险的？

In a PHP / Apache / Linux context, why exactly is chmod 777 dangerous?

评论

评论

评论