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

概述您知道您可以使用.htaccess将服务器解析 HTML页面作为 PHP(在HTML文档中执行 PHP代码)？ 那么有人说这样做是坏的.为什么？ 有些人还表示在您的应用程序中打开安全漏洞.怎么样？ 在文件到达浏览器之前,源代码仍然被删除,所以不可能是未经授权的访问源代码,对吧？ 让我从一个小故事开始：回到当我在Linux发行版供应商的安全联系人时,PHP安全团队要求Linux供应商停止调用解释器崩 您知道您可以使用.htaccess将服务器解析 HTML页面作为 PHP(在HTML文档中执行 PHP代码)？

那么有人说这样做是坏的.为什么？

有些人还表示在您的应用程序中打开安全漏洞.怎么样？

在文件到达浏览器之前,源代码仍然被删除,所以不可能是未经授权的访问源代码,对吧？

解决方法 让我从一个小故事开始：回到当我在linux发行版供应商的安全联系人时,PHP安全团队要求linux供应商停止调用解释器崩溃的安全漏洞,即使PHP解释器在Web服务器内运行(比如说,Apache上的mod_PHP). (当时,每周大概有一次翻译崩溃.)

他们进行了一些谈话,实际上说服我们,提供运行的PHP代码的人是完全信任的,并且任何尝试控制脚本可以从翻译器执行的 *** 作被误导 – 如果有人想出如何使解释器崩溃围绕它试图施加的限制(如entire silly safe mode pile of crap),这不是一个安全漏洞,因为脚本的安全执行不是PHP解释器的目标 – 它永远不会是永远不会的.

我对讨论的最终结果感到非常满意 – 它清楚地定义了PHP的安全目标：您应该只允许执行您100％完全信任的PHP代码.如果你不信任,你不会运行它.这很简单

无论 *** 作系统资源可用于解释器,都可以使用和公平的游戏,无论脚本是使用解释器中的错误还是发生意想不到的事情.

所以,请不要让随机代码在您的网络服务器的上下文中执行,除非这是您真正想要的.

请使用principle of least privilege指导每个程序可用的资源.

考虑使用AppArmor,SELinux,TOMOYO或SMACK等mandatory access control工具进一步限制您的程序可以做什么和不能做什么.自2001年以来,我已经在AppArmor项目上工作,相当有信心,通过一天的努力,大多数系统管理员可以通过AppArmor以有意义的方式增强他们的站点安全性.请评估几个选项,因为不同的工具围绕不同的安全模型设计 – 一个或另一个可能更适合.

但无论你做什么,请不要运行您的服务器,不必要地打开它,以通过额外的向量攻击.

总结

以上是内存溢出为你收集整理的为什么告诉您的服务器将HTML解析为PHP是一个坏主意？全部内容，希望文章能够帮你解决为什么告诉您的服务器将HTML解析为PHP是一个坏主意？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。