5

我有许多项目的功能依赖于 、 和 提供的$_SERVER['REMOTE_ADDR]IP$_SERVER['HTTP_X_FORWARDED_FOR']地址$_SERVER['CLIENT_IP']。

IPV4 地址很容易匹配，因为我们总是以相同的格式接收它们：4 个不带前导 0 的整数，用点分隔.。

而 IPV6 地址可以被压缩。例如：FF01:0:0:0:0:0:0:101 -> FF01::101

我一直在研究这个问题，但没有发现任何相关的东西，所以我想请教您的经验。是否$_SERVER['REMOTE_ADDR]使用标准？假设它总是以压缩或未压缩的形式接收是否安全？

或者我应该在尝试测试它们之前压缩所有的 IPV6 字符串？

笔记：

理想情况下，我想将 IPV6 地址作为字符串而不是二进制结构来处理，以提高数据库/源代码的可读性并允许更轻松的 IP 范围匹配。

4

3 回答 3

5

如果您inet_pton()先使用，然后将其转换回字符串，则inet_ntop()应该具有一致的字符串表示形式。我不会依赖输入来保持一致......

于 2012-04-25T15:42:50.657 回答
2

CGI 规范清楚地表明任何符合 RFC 的 IPv6 地址都是有效的：

4.1.8.  REMOTE_ADDR

   The REMOTE_ADDR variable MUST be set to the network address of the
   client sending the request to the server.

      REMOTE_ADDR  = hostnumber
      hostnumber   = ipv4-address | ipv6-address
      ipv4-address = 1*3digit "." 1*3digit "." 1*3digit "." 1*3digit
      ipv6-address = hexpart [ ":" ipv4-address ]
      hexpart      = hexseq | ( [ hexseq ] "::" [ hexseq ] )
      hexseq       = 1*4hex *( ":" 1*4hex )

  The format of an IPv6 address is described in RFC 3513 [15].

一个理智的程序员会验证所有的输入。因此，您应该将任何环境变量视为受污染的输入并验证/转换。客户提供的标头（例如 X-Forward-For 等）应始终受到怀疑。

那么扩展 IPv6 地址呢？

这个问题之前已经被问过，有几个解决方案，包括PEAR 一个

希望这可以帮助！

于 2012-04-25T15:39:05.610 回答
1

IPv6 地址的推荐格式在RFC 5952中。

但是，您不能依赖所有地址都采用该格式，并且字符串格式对于范围比较特别糟糕。阅读 RFC 将使您了解合法地表示同一 IPv6 地址的方法有多少。

您确实应该解析地址（使用inet_pton其他地方提到的）并在生成的 128 位字段上执行范围比较。

通常情况下，您只会关心 64 个最高有效位，这非常适合long大多数架构。

于 2012-04-25T15:37:20.713 回答