php - 为什么告诉您的服务器将 HTML 解析为 PHP 是一个坏主意？

Question

您知道您可以使用 .htaccess 使服务器将 HTML 页面解析为 PHP（在 HTML 文档中执行 PHP 代码）吗？

好吧，有些人说这样做不好。为什么？

有些人还说它会在您的应用程序中打开一个安全漏洞。如何？

在文档到达浏览器之前源代码仍然被删除，所以不会出现未经授权访问源代码的情况，对吧？

Answer 1

让我从一个小故事开始：当我在一家 Linux 发行版供应商担任安全联系人时，PHP 安全团队请求 Linux 供应商停止调用解释器崩溃安全漏洞，即使 PHP 解释器在 Web 服务器中运行（例如，mod_php在 Apache 上）。（当时，每周大约会发现一次口译员崩溃。）

他们花了一点点谈话才真正说服我们，提供运行 PHP 代码的人是完全受信任的，任何试图控制脚本可以从解释器执行的操作都是错误的——如果有人想出了如何使解释器崩溃绕过它试图强加的限制（例如整个愚蠢的安全模式一堆废话），这不是安全漏洞，因为脚本的安全执行不是PHP 解释器的目标——它从来没有，也从来没有将会。

实际上，我对讨论的最终结果非常满意——它清楚地定义了 PHP 的安全目标：您应该只允许执行您 100% 完全信任的 PHP 代码。如果您不信任它，就不要运行它。就是这么简单。

无论脚本是否利用了解释器中的错误或只是做了一些意想不到的事情，解释器可以使用的任何操作系统资源都是可用的并且是公平的游戏。

因此，请不要让随机代码在您的网络服务器的上下文中执行，除非那是您真正想要的。

请使用最小权限原则来指导每个程序可以使用哪些资源。

考虑使用强制访问控制工具，例如AppArmor、SELinux、TOMOYO或SMACK来进一步限制您的程序可以做什么和不能做什么。我从 2001 年左右开始从事 AppArmor 项目，并且相当有信心通过一天的努力，大多数系统管理员可以使用 AppArmor 以一种有意义的方式增强他们的站点安全性。请评估几个选项，因为不同的工具是围绕不同的安全模型设计的——一个或另一个可能更合适。

但是无论您做什么，请不要以不必要的方式运行您的服务器，从而通过额外的向量对其进行攻击。

Answer 2

主要问题是如果您将代码移动到另一台服务器或让其他人使用您的代码、服务器设置或.htaccess文件，您的 html 页面可能会停止被 PHP 解释器解析。

在这种情况下，PHP 代码将提供给浏览器。

Answer 3

存在一个安全漏洞，如果您这样做，HTML 文件实际上是 PHP 文件，因此上传它们应该像上传 PHP 文件一样认真对待。人们通常不认为上传 HTML 文件有什么大不了的，正是因为他们不希望它们被设置为解析为 PHP（因此您公司中的其他人可能会无意中打开一个安全漏洞）。[PaulP.RO 的回答指出，安全问题也可能出现在相反的方向 - 由于 PHP 在稍后错误地删除此设置时被误认为是 HTML。]

还有一点性能问题，因为每个 HTML 文件都必须通过 PHP 解析器运行（即使它恰好不包含 PHP）。

Answer 4

出于速度和组织的原因，将 HTML 解析为 PHP 是不好的（ish）。

• 解析为 PHP 的 HTML 文件在技术上会加载较慢，因为您正在调用 PHP 引擎。
• 但大多数情况下，这对组织目的不利：随着项目的扩展，想象一下在 HTML 文件中寻找嵌入的 PHP 代码。浏览您的项目时，您的文件扩展名应该是该文件用途的真正指标。如果表单提交到“login.php”，您可以合理地确定它包含服务器代码。但“login.html”可能只是另一个 HTML 页面。

关于您的其余评论，我不确定安全方面，但我认为混合您的 HTML 和 PHP 输出可能会导致未被注意到的 XSS 漏洞？不过，这不是专家。

Answer 5

这对速度不利，如果 PHP 解释器由于某种原因无法工作，PHP 代码将显示在页面源代码中。例如，如果您在 PHP 代码中有数据库用户名和密码，那么任何人都可以轻松连接和访问您的数据库。

正如 zed 所说，出于组织原因，这很糟糕。您需要更新站点上的所有文件以进行简单更改，而不是更新一个文件。

Answer 6

允许服务器将 HTML 文件解析为 PHP 表明您没有使用适当的应用程序设计模式。也就是说，你是在开辟自己的道路，而不是按照推荐的方式做事。存在像 MVC（关注点分离）这样的设计是有原因的。

允许直接调用任意文档的一个问题是丢失了“前端控制器”（通常是 index.php），这有助于减少进入应用程序的入口数量。

您可以有许多进入应用程序的路径，但您必须在设计中涵盖更多可能的攻击路线。