如果用户输入对命令或其参数没有影响，则不应该有直接的威胁。

但这总是有风险的，您可能会遗漏某些东西，或者您正在使用的软件（例如，Django）中可能存在（即肯定存在）未知漏洞。

为了减轻这些情况，我会做的是：

1. 验证您的权限。确保您使用所需的那些操作所需的最低权限（也许 Apache 的用户对您需要的权限太高，创建另一个权限较低的用户）；
2. 仅将您需要的命令列入白名单（阻止其他所有命令）；
3. 考虑为这些操作设置受控文件系统（例如，某种“chroot”）；
4. 强化你的服务器（研究 Grsecurity 和 RBAC）；
5. 显然保持所有的补丁和更新。

当您构建包含用户提供的字符串的命令时，总是存在命令注入的风险。

应该将文件复制到用户提供的名称的示例代码：

$command = "cp template.png " + $filename + ".png";

当用户提供文件名时，他们可以传递：

$filename = "foo.png ; rm *";

导致操作系统接收

cp template.png foo.png ; rm *.png

这实际上是两个命令，第二个是恶意的（从目录中删除所有 png 文件）。

是的，它可以！这是非常不安全的，被认为是安全行业最糟糕的做法之一。有很多事情可能出错：

• 你可以让人们输入他们想要的任何命令，很快他们就会让你的服务器下载并执行他们自己制作的恶意二进制文件。
• 您可能会遭受@Philipp 所描述的一类攻击，称为“操作系统命令注入”。它发生在您对用户提供的数据执行命令时，并且用户向您提供数据，以便他们将额外的命令序列附加到它。解决此问题的最佳方法是编写一个函数，该函数将分别接收命令和数据并始终清理/转义数据。
• 即使您将自己限制为 cp 和 mv 之类的几个命令，用户也可能会提供指向您工作目录之外的文件名，例如“/usr/bin/apache”，在@Philipp 的示例中，这会导致您的 Apache 二进制文件被删除并且您的下次重新启动时服务器不再工作。

现在，我不知道您要做什么，但如果您坚持继续，请记住以下几点：

• 验证您的用户，并验证他们是否有权使用您的视图
• 仅允许白名单内的命令，并如上所述分离命令和数据
• 通过转义特殊字符并验证它是否属于合法空间（例如，文件名在合法空间内，例如不包含任何文件夹名称）来系统地清理数据；参见克拉克-威尔逊模型
• 沙箱你的 Web 服务器，如果可能的话，让一个特定的服务器/工作者来运行你的这个特殊视图（参见 Apache 的 SELinux 模块，特别是看看 RHEL 7 如何使用 SELinux 和 systemd 来沙箱服务）；如果同一台服务器运行任何实际敏感的东西并包含在 LXC 或 Docker 容器中运行 Web 视图的服务器（尚不完全安全，但总比没有好），那就更进一步
• 让外部渗透测试团队审核您的代码和服务器