Dem*_*a ツ 6 php security joomla
一些托管服务提供商禁用了 PHP 函数 parse_ini_file()。
任何在那里使用它的尝试都会失败，并显示错误“出于安全原因，parse_ini_file() 已被禁用”。
这种配置非常普遍，以至于作为最流行的 CMS 之一的 Joomla 避免了直接使用 parse_ini_file() ，而是将任务分为两步：
我的问题是，如何使用 parse_ini_file()会被视为安全威胁，或者如何禁用 PHP 函数 parse_ini_file() 可以提高安全性？
会不会是个骗局？
我的意思是，也许在过去的某个地方，有人将 parse_ini_file() 与 ini_set() 混淆，并认为 parse_ini_file() 可以更改 PHP 环境的配置。
博主可以在这里和那里提供建议，而天真的系统管理员可以不问自己任何问题就遵循这些建议。
该限制parse_ini_file尝试防范的安全风险是从任意文件读取，而不是解析其内容。
如果您能够读取通常不应访问的文件（例如系统的密码文件；或属于其他用户的用户），则从任意文件中读取可被视为安全威胁。即使文件不是 ini 格式，返回的结果parse_ini_file()仍然可能提供信息。
在 PHP <= 5.3.x 中，在启用安全模式时parse_ini_file() 受到限制。在 PHP >= 5.4 中，删除了安全模式（有利于要求实际的系统级安全性，而不是这种语言在玩打地鼠的失败游戏，具有越来越多的功能，可以以越来越有创意的方式读取任意文件）。
禁止的建议parse_ini_file()是旧的，从安全模式仍然存在的时候开始。它并不比任何其他读取文件的 PHP 函数更危险。parse_ini_file()现在禁止的托管服务提供商（尤其是在file_get_contents()开放之后被误导，根据不再有效的旧建议进行操作，并且即使在有效时也有可疑的好处。
PHP 源代码中的代码parse_ini_file()基本上归结为调用与 相同的代码parse_ini_string，只是初始化模式略有不同（这样一个可以从文件中读取，另一个可以从字符串中读取）。否则，他们使用相同的代码来实际解析 ini 文件并返回结果。