0

我最近将我的公司网站从托管公司 (IIS) 转移到了我们的内部服务器 (Apache)。最初建立该站点的小组做得很差，整个迁移过程一团糟。虽然移动相当顺利，但查看 error_log 仍然有一些缺失的页面。

而不是必须不断地通过错误日志来查找与该域相关的“文件不存在”错误 - 我们在这些服务器上托管了大约 15 个左右 - 我想知道当 404 时简单地执行以下操作是否会更容易发生错误：

  • 重定向到 php 页面并传递原始 URL 请求
  • 让新的 php 页面将 URL 转储到 log-ish 文件

当我打字时，我越来越不相信这是一项有价值的工作。不管潜在的问题是，使用 fwrite 是否存在潜在的安全问题？如果要将输入附加到文件中，是否需要对用户输入进行任何类型的清理？无论价值如何，这个输入都不会靠近数据库。提前致谢。

4

7 回答 7

3

只要您是定义要写入哪个文件的人（而不是从 URL 确定），就不会有太大风险：您从用户那里得到的唯一东西就是您将写入文件的内容，如果您不执行该文件，而只是阅读它，则应该没问题。

以这种方式记录 404 错误的想法并不新鲜：我已经看到它完成了很多次，并且从未遇到过任何重大问题（我看到的最大问题是文件变得非常快，因为有很远错误太多^^)

例如，Drupal 做了一些这样的事情：记录 404 错误——但是记录到数据库中，因此使用 Web 界面更容易分析它们。

于 2009-12-23T13:52:22.990 回答
1

好吧，只是通常的文件系统内容：不要让用户指定文件的去向：script.php?filename=../../../../../../../etc/passwd甚至不应该有机会写入 /etc/passwd （脚本也不应该有 FS 权限） . 除此之外， fwrite() 没有任何特殊字符可以让它跳转到某种命令模式。

此外，404 页面非常简单（在 httpd.conf 中）：

ErrorDocument 404 /error_page.php

并将其转储REQUEST_URL到文件中

于 2009-12-23T13:49:39.050 回答
0

fwrite 应该很安全。

或者，您可以使用一些通常列出未找到页面的访问日志分析器。

于 2009-12-23T13:49:54.947 回答
0

如果它所做的只是写入磁盘，那么外界唯一要做的就是让它写入磁盘。显然，文件名不应该是与无效 url 一起传递的参数。有些人可能会尝试通过发送大量带有非常长 url 的无效页面请求来利用它。但是他们必须知道你正在这样做，并且当有其他更有效的方法只是一般攻击时，他们必须足够关心。

于 2009-12-23T13:53:20.647 回答
0

需要注意的一个潜在问题是，您是否将日志编写为 HTML（或其他恰好允许嵌入代码的文件类型）。这些文件当然容易受到 XSS 攻击。

于 2009-12-23T16:13:17.380 回答
0

一种常见的日志文件攻击是请求包含嵌入式恶意 javascript 的 URL。这些 URL 被直接写入日志文件，然后当任何人在 Web 浏览器中查看该文件时执行该文件。

  1. 确保您编写的文件不能被 Web 服务器作为 HTML 提供
  2. 考虑对 URL 进行 URL 编码或 HTML 编码。
于 2009-12-23T16:13:48.783 回答
0

您应该已经在 error_log 中记录了 404 错误。

无论如何，使用自定义错误处理程序为用户提供更友好的错误消息，但如果该站点看到任何严重的吞吐量，那么从脚本中使用 fwrite 不是一个好主意。PHP 本身并没有那种复杂的文件锁定语义来支持并发文件访问——但既然网络服务器正在为你记录信息，何必呢？

于 2009-12-23T18:09:34.850 回答