在“自然”HTTP 404 和 PHP 生成的 HTTP 404 之间进行区分答案

【问题标题】：Telling between a "natural" HTTP 404 and a PHP Generated one在“自然”HTTP 404 和 PHP 生成的 HTTP 404 之间进行区分
【发布时间】：2011-06-04 19:37:49
【问题描述】：

所以我有一个文件应该从不由用户直接访问，但包含在另一个 PHP 文件中。如果直接调用该文件，它会生成 HTTP Status 404 Not Found 以欺骗可能的攻击者该文件不存在。但是，如果黑客能够分辨出 404 是由 PHP 生成的或者不是“自然的”，那么标头的整个点就会丢失。那么是否可以判断 404 是由服务器自然生成（因为该文件确实不存在）还是由 PHP 代码生成？

PS：我知道这个问题可能看起来很奇怪，哈哈

【问题讨论】：

这并不能直接回答您的问题...但是为什么不使用403 forbidden 代码呢？
RFC2616 指出，当服务器不希望显示拒绝请求的确切方式时，404 状态代码可用于指示拒绝响应请求。 w3.org/Protocols/rfc2616/rfc2616-sec10.html
@Nick：我不是 OP，但我想 403 禁止会让攻击者（尤其是自动攻击者）知道“嘿，那个文件在那里，我在正确的轨道上”
艾伦是对的，哈哈，他不是我，但他对攻击者知道文件在那里也是对的！
给自己一个 http 嗅探器，记下服务器发出的常规 404 标头，然后在脚本中模拟它们。简单易懂

标签： php http http-headers http-status-code-404

【解决方案1】：

聪明的攻击者会检查原始状态标头并寻找任何可能表明某事是否为“自然”404 的差异。

例如，如果您请求的文件不存在，我服务器上的 Apache 版本会发回以下标头

HTTP/1.1 404 Not Found
Date: Thu, 06 Jan 2011 18:10:57 GMT
Server: Apache/2.2.17
Content-Type: text/html

但是，如果我设置一个 PHP 页面来发回 404 标头，我的服务器会发回以下标头

HTTP/1.0 404 Not Found
Date: Thu, 06 Jan 2011 18:10:48 GMT
Server: Apache/2.2.17
Connection: close
Content-Type: text/html

所以，显然并没有表明是 PHP 在第二种情况下生成了标头，但那是额外的

Connection: close

header 表示还有其他事情发生。非常老练的攻击者已经为尽可能多的 Web 服务器和动态运行时构建了默认标头配置文件，这些配置文件会查看标头的确切内容和顺序，以确定您可能运行的服务器和技术堆栈。一个老练的攻击者会知道（或有一个工具表明）PHP 总是发送一个 Connection: close 标头，这可能会泄露您的基础技术。

我使用命令行程序curl 来检查标题。

curl -I 'http://example.com/asfasdfsd'

您可以在OWASP wiki 上找到更多信息。

同样，确保您的 PHP 页面发回的原始文本与您的 Apache 服务器发回的字节级别的内容相匹配。聪明的攻击者会寻找输出格式的差异，以确定您的页面是否是“自然”404。

【讨论】：

HTTP/1.0 而不是 HTTP/1.1 也可能会给出提示
@Mark：是的，那是我自己的错，因为我使用了我古老的 PHP 标头代码示例。如果您的标头签名与任何已知的服务器基线不匹配，则攻击可能会怀疑他们正在处理动态 404
不是想象中的弹片上校，我只是注意一下。请参阅我刚刚添加到帖子中的 OWASP 链接（在 cmets 中中断）。

【解决方案2】：

唯一的方法是判断 PHP 生成的页面是否与 Web 服务器生成的页面不同。否则没有区别。

您还应该将 PHP.ini 中的 expose_php 值设置为关闭，这样 PHP 就不会插入“由...生成”等标题。见http://blog.arvixe.com/expose-php-servertokens-apache/

【讨论】：

【解决方案3】：

如果可能的话，我建议您将不应直接提供的文件放在 DOCUMENT_ROOT 之外。

【讨论】：

【解决方案4】：

这并不能回答问题，但这里有一个相关提示：用户不应直接访问的文件应放在 Web 服务器的文档根目录之外。

【讨论】：

【解决方案5】：

只要HTTP返回状态码是404，那么它就是定义，一个真正的404，不管返回什么其他内容。

但我认为你可能问错了问题。

应保护内部包含的文件，例如，将它们放入自己的目录中，并使用.htaccess 或其他网络服务器指令拒绝对该目录的所有访问。这样您就不必担心“保护”每个内部文件，也不必担心编程错误会意外让某人进入。

【讨论】：

问题是我不知道我是否要将其他应该可以访问的数据存储在同一目录中。不过我会考虑的。