我们有几个开发人员要求在我们的服务器上启用allow_url_fopen。这些天的规范是什么，如果启用了" libcurl"，是否真的有充分的理由允许这样做？

环境是：Windows 2003，PHP 5.2.6，FastCGI

解决方案

我们肯定希望将" allow_url_include"设置为" Off"，这也减轻了" allow_url_fopen"的许多风险。

但是由于并非所有版本的PHP都具有allow_url_include，因此许多最佳做法是关闭fopen。与所有功能一样，现实是如果应用程序不需要它，请将其禁用。如果确实需要它，curl模块可能会做得更好，并且重构应用程序以使用curl禁用allow_url_fopen可能会阻止最少确定的破解者。

跨站点脚本攻击是一件痛苦的事，因此是一票反对。而且我们应该绝对将" allow_url_include"设置为关闭，否则我们将遭受重创。

我认为答案归结为我们对开发人员负责任地使用该功能的信任程度如何？来自外部URL的数据应像其他任何不受信任的输入一样对待，只要能理解，有什么大不了的？

我的看法是，如果我们像对待孩子一样对待开发人员，并且从不让他们处理尖锐的事情，那么我们将拥有从未学习编写安全代码的责任的开发人员。

这取决于开发的类型。如果原型是可以的，那么启用" allow_url_fopen"就可以了，但是libcurl和file_get_contents之间没有明显的速度差异，启用它只是为了方便。

对于生产服务器，应将对libcurl的任何调用标记为安全审核。如果启用了" allow_url_fopen"，则应该fopen和file_get_contents。禁用" allow_url_fopen"并不能阻止漏洞利用，仅会稍微限制其实现方式的数量。

最大的问题是allow_url_fopen的安全性更高，因此，如果要使用curl从URL保存文件，则必须从fopen / file_get传递以保存文件。

CURL is only good to retrieve remote content from URL.
  (allow_url_fopen not necessary)
  CURL must be added with Fopen or File_get if you want to save remote
  file to your server.
  (allow_url_fopen obligatory with CURL)

PHP必须找到其他方法来使其更加安全。