PHP函数parse_ini_file（）真的那么危险吗？

少数主机提供程序禁用PHP函数parse_ini_file（）。
在那里使用它的任何尝试都将失败，错误为“出于安全原因，已禁用parse_ini_file（）。
这种配置非常常见，Joomla是最流行的CMS之一，它避免直接使用parse_ini_file（），而是将任务分为两个步骤：

使用file\u get\u contents（）读取文件内容

使用parse_ini_string（）解析值，这是被奇怪地允许的，因此它不被认为是安全风险（WTF？）

我的问题是，使用parse_ini_file（）如何被视为安全威胁，或者禁用PHP函数parse_ini_file（）如何提高安全性

这会是一场恶作剧吗？
我的意思是，也许过去有人把parse_ini_file（）和ini_set（）搞混了，认为parse_ini_file（）可以改变PHP环境的配置。

---

博客作者可以在这里或那里提供建议，天真的系统管理员可以遵循这些建议，而不必问自己任何问题。

对

解析ini\u文件的限制试图防范的安全风险是从任意文件读取，而不是解析其内容

如果您能够读取通常不应访问的文件（例如，系统密码文件；或属于其他用户的用户），则从任意文件读取可能会被视为安全威胁。即使文件不是ini格式，由
parse_ini_file（）
返回的结果仍然可能提供潜在的信息

在PHP=5.4中，安全模式被删除（为了要求实际的系统级安全性，而不是玩一个失败的“打鼹鼠”游戏的语言，它有越来越多的功能，可以以越来越有创意的方式从任意文件中读取）

禁止
parse_ini_file（）
的建议是一个古老的建议，从安全模式还是一种东西的时候开始。它并不比从文件读取的任何其他PHP函数更危险。现在禁止
parse\u ini\u file（）
的主机提供商（特别是在离开
file\u get\u contents（）
打开后）是错误的，使用的是不再有效的旧建议，即使在有效时也有可疑的好处

parse_ini_file（）
的PHP源代码本质上归结为调用与
parse_ini_string
相同的代码，只是初始化模式略有不同（这样一个可以从文件中读取，另一个可以从字符串中读取）。否则，他们将使用相同的代码来实际解析ini文件并返回结果。
我找不到合理的理由来禁用它。我的提示：询问主机提供商谁会这样做。；）谢谢，但这并不能解释为什么在禁用parse_ini_file（）的主机上，会启用file_get_contents（）。如果他们想阻止文件打开，他们也应该禁用file_get_contents（）。@Fox，因为这是一种误导性的安全尝试，源于对不再适用的旧建议的误解。如果要让
file\u get\u contents（）
保持打开状态，则没有充分的理由禁用
parse\u ini\u file（）
。