PHP 函数 parse_ini_file() 真的那么危险吗？

Question

一些托管服务提供商禁用了 PHP 函数 parse_ini_file()。
任何在那里使用它的尝试都将失败，并出现错误“parse_ini_file() 出于安全原因已被禁用”。
这种配置非常普遍，以至于作为最流行的 CMS 之一的 Joomla 避免直接使用 parse_ini_file() ，而是将任务分为两步：

1. 使用 file_get_contents() 读取文件内容
2. 使用 parse_ini_string() 解析值，这是奇怪的允许，因此它不被视为安全风险 (WTF?)

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

会不会是骗局？
我的意思是，也许有人在过去的某个地方将 parse_ini_file() 与 ini_set() 混淆了，并认为 parse_ini_file() 可以更改 PHP 环境的配置。
博主可能会在这里和那里提出建议，而天真的系统管理员可能会在不问自己任何问题的情况下遵循这些建议。

Answer 1

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

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

在 PHP parse_ini_file() was restricted 当 safe mode 启用时。在 PHP >= 5.4 中，删除了安全模式（有利于要求实际系统级安全性，而不是语言玩一个失败的打地鼠游戏，具有越来越多的功能可以读取以越来越有创意的方式从任意文件中提取）。

禁止parse_ini_file() 的建议是旧的，从那时起，安全模式还很流行。它并不比任何其他从文件读取的 PHP 函数更危险。现在禁止parse_ini_file() 的托管服务提供商（尤其是在将file_get_contents() 保持开放状态后）是被误导的，它根据不再有效的旧建议进行操作，即使它有效，也有可疑的好处。

parse_ini_file() 的 PHP 源代码中的代码本质上归结为调用与 parse_ini_string 相同的代码，只是初始化模式略有不同（这样一个可以从文件中读取，而另一个可以从字符串中读取） .否则，他们将使用相同的代码来实际解析 ini 文件并返回结果。