我最近将我的公司网站从托管公司（IIS）转移到我们的内部服务器（Apache）。最初建立该网站的团队做了一个糟糕的工作，整个事情都是一团糟迁移。虽然这一举措相当顺利，但查看error_log仍然有一些缺失的页面。php fwrite中的安全漏洞？
而不是不断地grep通过error_log“文件不存在”与此域相关的错误 - 我们有大约15左右，我们在这些服务器上承载 - 我想知道是否可能更容易做到简单做当出现以下404错误：
当我键入这使我越来越不相信这一点是值得的事情。尽管潜在的问题是，使用fwrite是否存在潜在的安全问题？如果输入要附加到文件中，是否需要进行任何类型的用户输入清理？这个输入不会在任何值得的数据库附近进行。提前致谢。
只要你是一个定义哪些文件，你正在编写（而不是确定自该URL），应该不会有太大的风险：你会从用户那里得到的唯一的事情就是你要写入文件的内容，如果你不执行该文件，但只是阅读它，它应该是相当好的。
以这种方式记录404错误的想法并不新鲜：我已经看到它完成了好几次，并且从未遇到过任何主要问题（我看到的最大问题是一个文件变得很大，速度很快，因为有太多的错误^^）
例如，Drupal做了这样的事情：记录404错误 - 但是对于数据库，因此使用Web界面分析它们更容易。
那么，只是通常的文件系统的东西：不要让用户指定文件将去的地方：像script.php?filename=../../../../../../../etc/passwd的东西甚至不应该有写入/ etc/passwd的机会（脚本不应该有FS的权限）。 除此之外，fwrite（）没有任何特殊字符允许它跳入某种命令模式。
另外，404页（在httpd.conf）很简单：
ErrorDocument 404 /error_page.php
，只是转储REQUEST_URL到文件
FWRITE应该是相当安全的。
或者，您可以使用一些通常列出未找到页面的访问日志分析器。
如果它所做的只是写入光盘，外部的唯一一个人就是让它写入光盘。很明显，文件名不应该是一个通过无效url传递的参数。有些人可能会尝试通过发送大量无效的页面请求与真正长的URL进行利用。但是，如果有其他更有效的方法，那就是普通攻击，但他们必须知道你正在做这件事，并且非常关心。
如果您将日志编写为HTML（或其他允许嵌入代码的文件类型），则需要注意的潜在问题是。这些文件当然容易受到XSS攻击。
常见的日志文件攻击是请求包含嵌入的恶意JavaScript的URL。这些URL会直接写入日志文件，然后在任何人在Web浏览器中查看文件时执行。
您应该已经在您的error_log中记录了404个错误。
通过一切手段使用自定义错误处理程序给用户一个友好的错误消息，但如果此网站看到任何形式的严重吞吐量，然后从脚本使用fwrite不是一个好主意。为了支持并发文件访问，PHP本质上没有一种复杂的文件锁定语义 - 但是由于Web服务器正在为您记录信息，为什么要麻烦？
写作很好。您的安全漏洞来自文件被查看，解释或执行的时间。 – Cheekysoft 2009-12-23 16:15:20