您知道您可以使用 .htaccess 使服务器将 HTML 页面解析为 PHP（在 HTML 文档中执行 PHP 代码）吗？
好吧，有些人说这样做不好。为什么？
有些人还说它会在您的应用程序中打开一个安全漏洞。怎么样？
在文档到达浏览器之前，源代码仍然被删除，所以不会出现未经授权访问源代码的情况，对吧？
【问题讨论】：
标签： php html security parsing .htaccess
让我从一个小故事开始：当我在一家 Linux 发行版供应商担任安全联系人时，PHP 安全团队请求 Linux 供应商停止调用解释器崩溃安全漏洞，即使 PHP解释器正在在 Web 服务器中运行（例如，Apache 上的mod_php）。 （当时，每周大约会发现一次解释器崩溃。）
他们花了一点时间交谈才真正说服我们，提供运行 PHP 代码的人是完全受信任的，任何试图控制脚本可以从解释器做什么的尝试都是错误的——如果有人想出了如何使解释器崩溃以绕过它试图施加的限制（例如entire silly safe mode pile of crap），那不是安全漏洞，因为脚本的安全执行是不是 PHP 解释器的目标——它从来没有，也永远不会。
实际上，我对讨论的最终结果非常满意——它明确定义了 PHP 的安全目标：您应该只允许执行您 100% 完全信任的 PHP 代码。如果您不信任它，就不要运行它。就这么简单。
无论脚本是利用解释器中的错误还是只是做了一些意想不到的事情，解释器可以使用的任何操作系统资源全部都是可用且公平的。
所以，请不要让随机代码在您的网络服务器的上下文中执行，除非这是您真正想要的。
请使用principle of least privilege 来指导每个程序可以使用哪些资源。
考虑使用mandatory access control 工具，例如AppArmor、SELinux、TOMOYO 或SMACK，以进一步限制您的程序可以做什么和不能做什么。我从 2001 年左右开始从事 AppArmor 项目，并且相当有信心通过一天的努力，大多数系统管理员可以使用 AppArmor 以一种有意义的方式增强他们的站点安全性。请评估几个选项，因为不同的工具是围绕不同的安全模型设计的——一个或另一个可能更合适。
但无论您做什么，请不要以不必要的方式运行您的服务器，从而通过额外的向量对其进行攻击。
【讨论】：
主要问题是如果您将代码移动到另一台服务器或让其他人使用您的代码、服务器设置或.htaccess 文件，您的 html 页面可能会停止被 PHP 解释器解析。
在这种情况下，PHP 代码将提供给浏览器。
【讨论】：
有一个安全漏洞，如果您这样做，HTML 文件实际上是 PHP 文件，因此上传它们应该像上传 PHP 文件一样认真对待。人们通常不认为上传 HTML 文件有什么大不了的，正是因为他们不希望它们被设置为解析为 PHP（因此您公司中的其他人可能会无意中打开一个安全漏洞）。 [PaulP.R.O. 的回答指出，安全问题也可能出现在相反的方向 - 由于 PHP 稍后在错误地删除此设置时被误认为是 HTML。]
还有一点性能问题，因为每个 HTML 文件都必须通过 PHP 解析器运行（即使它碰巧不包含 PHP）。
【讨论】：
由于速度和组织方面的原因，将 HTML 解析为 PHP 是不好的。
关于您评论的其余部分，我不确定安全方面，但我认为混合您的 HTML 和 PHP 输出可能会导致未被注意到的 XSS 漏洞？但在这方面不是专家。
【讨论】：
这对速度不利，如果 PHP 解释器由于某种原因无法工作，PHP 代码将显示在页面源代码中。例如，如果您在 PHP 代码中有数据库用户名和密码，那么任何人都可以轻松连接和访问您的数据库。
正如 zed 所说，出于组织原因，这很糟糕。您不需要更新一个文件，而是需要更新您网站上的所有文件以进行简单的更改。
【讨论】：
允许服务器像 PHP 一样解析 HTML 文件表明您没有使用适当的应用程序设计模式。也就是说，你是在开辟自己的道路，而不是按照推荐的方式做事。存在像 MVC（关注点分离）这样的设计是有原因的。
允许直接调用任意文档的一个问题是丢失了“前端控制器”（通常是 index.php），这有助于减少进入应用程序的入口数量。
您可以有许多进入应用程序的路径，但您必须在设计中涵盖更多可能的攻击路线。
【讨论】：