在 PHP / Apache / Linux 环境中，为什么 chmod 777 到底很危险？

问题描述：

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

我们都被告知，将目录或文件留在基于 Linux 的网络托管上并具有权限级别777是一件坏事，并且应始终设置尽可能少的权限。

我现在很好奇，漏洞的危险究竟在哪里，特别是在 PHP / Apache 环境中。

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

那么漏洞究竟在哪里777？是不是同一台计算机上的其他用户可以访问设置为全球可写的文件？

解决方案 1：

以下是一种情况：

1. 您有一个不受保护的目录，用户可以上传内容。

2. 他们上传了两个文件：一个 shell 脚本和一个system()包含对 shell 脚本的调用的 php 文件。

3. 他们通过浏览器中访问 URL 来访问刚刚上传的 php 脚本，从而导致 shell 脚本执行。

如果此目录的权限为 777，则意味着任何人（包括用户 apache，php 脚本将以此用户身份执行）都可以执行它！如果该目录以及目录内的文件未设置执行位，则上述步骤 3 将不执行任何操作。

从评论中编辑：重要的不是 PHP 文件的权限，而是system()PHP 文件内部的调用，该调用将由 Linux 用户 apache（或您将 apache 设置为以任何方式运行）作为 Linux 系统调用执行，而这正是执行位重要的地方。

解决方案 2：

这极大地增加了您的网站遭受恶意活动的漏洞，因为只需要侵入一个帐户。

任何以任何登录方式访问您系统的人都可以对您的页面进行任何他们想做的事情，包括将其更改为“该网站确实不安全，因此请向我提供您的信用卡信息”。

编辑：（澄清并处理评论）

许多服务器的用途不止一个。它们运行多种服务。如果您通过为每个服务分配一个唯一用户并相应地管理文件权限来仔细隔离这些服务，是的，如果有人泄露了帐户的凭据，您仍然会陷入困境，但他们能造成的损害仅限于这一项服务。如果您只有一个通用帐户并将整个文件系统设置为 777，那么一个被盗用的帐户会危及机器上的所有内容。

如果您的服务器专用于运行 Apache/PHP 并且没有其他用途，并且只有一个帐户运行 Apache/PHP，那么从应用程序的角度来看，该帐户被入侵就等于整台机器被入侵（尽管您仍然应该保护系统文件，并且使用于运行 PHP 的帐户无法写入……但这仍然只有管理员帐户/root 才有可能）。

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

解决方案 3：

在权限方面，遵循极简主义有很多很好的一般原因，但在 LAMP 网站托管的背景下，很容易想到的几个是

• 在共享托管平台上，共享您主机的其他用户现在可以读取和写入您的脚本。

• 在专用主机上，恶意进程可以读取/写入并意外删除您的文件。假设有一个自定义日志记录进程在后台以用户 nobody 的身份运行，该进程有一个错误，导致它尝试rm -rf /。现在一般来说，这将是无害的，因为几乎没有任何文件是 nobody 应该有写入权限的，但这个恶意进程现在会带走您的文件。

• 要破坏您的网站，有人只需以任何用户的身份获得访问权限，甚至说nobody是虚拟帐户。通常，攻击者必须进行进一步的用户级别升级攻击才能到达可以造成损害的地方。这是一个真正的威胁。一些非关键服务可能在虚拟帐户下运行，并且可能包含漏洞。

解决方案 4：

假设您的服务器上安装了一个软件包，并且其中存在零日漏洞，攻击者可以访问您的管理控制面板并具有上传文件的功能，如果您将所有内容都设置为 777，那么他就可以轻而易举地将 shell 脚本上传到他想要的任何地方。但是，如果您正确设置权限，他就无法做到这一点，因为 nobody/www-data/etc 没有写入权限。