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