会话劫持预防
将会话绑定到 IP 地址是一种很好的做法，这可以防止大多数会话劫持情况（但不是全部），但是有些用户可能会使用匿名工具（例如 TOR），并且他们会对您的服务产生问题。
要实现这一点，只需在第一次创建会话时将客户端 IP 存储在会话中，然后强制它保持相同。下面的代码片段返回客户端 IP 地址：
$IP = (getenv ("HTTP_X_FORWARDED_FOR")) ？getenv（“HTTP_X_FORWARDED_FOR”）：getenv（“REMOTE_ADDR”）；
来源：https ://www.owasp.org/index.php/PHP_Security_Cheat_Sheet#Session_Hijacking_Prevention
在我看来，这段代码很容易受到 IP 欺骗！对？
编辑：AFIK，X_FORWARDED_FOR 是一个 HTTP 标头，客户端很容易设置为他们想要的任何内容。
此代码允许知道受害者X-Forwarded-For:标头和受害者会话 ID的攻击者以该用户身份登录。如果受害者没有X-Forwarded-For:标头，攻击者可以将受害者的 IP 地址放在他的标头中，代码将使用该值作为他的合法 IP 地址，而不是他的实际 IP 地址。 这就是漏洞。
在网络嗅探场景中，攻击者同时获取这两个值，因此添加此代码并不能防止网络嗅探。
在 XSS 场景中，攻击者注入 javascript 以窃取用户的 cookie，这通常是通过使受害者的浏览器向攻击者控制的 Web 服务器发出请求，并将 cookie 值附加为 GET 参数来完成的。受害者的X-Forwarded-For:标头将在该请求中提供给攻击者。
我还没有想到攻击者可以获取受害者的 cookie 但无法获取合法X-Forwarded-For:标头的值的任何情况，或者如果没有标头，则无法获得受害者的 IP 地址。
所以答案是肯定的，正如所写，这段代码对提高安全性没有任何作用。它应该只信任直接连接的 IP 地址。
注意：如果您的 Web 应用程序服务器位于反向 Web 代理（例如 nginx、Varnish、HAProxy、mod_proxy、Amazon ELB 和许多其他代理）后面，该代理总是将连接 IP 地址添加到X-Forwarded-For标头并与您的 Web 应用程序服务器建立新连接使用它自己的 IP 地址，您可以“信任”此标头的部分值。
诸如 Apache 之类的模块mod_rpaf可以mod_remoteip使用受信任的代理 IP 地址列表进行配置，并将值替换为来自这些地址的连接REMOTE_ADDR的标头的受信任部分。X-Forwarded-For这REMOTE_ADDR将在 PHP 中可用，$_SERVER['REMOTE_ADDR]并将作为真正的连接 IP 地址记录在您的 Apache 日志文件中。
如果您不这样做（或者如果您不使用 Apache，则进行等效操作），那么您将只能看到来自一个 IP 地址的连接，即您的反向代理服务器，因此您的所有会话都将包含相同的 IP 地址。
我会说你是对的！他们似乎没有记住 HTTP 标头 X-FORWARDED-FOR 可能会返回'; DROP TABLE users;--.
他们建议这样做是为了也锁定代理背后的人的会话，并将 Tor 命名为示例。这有点愚蠢；出于明显的原因，Tor 从不转发原始 IP。此外，它甚至不（不应该？）查看数据包本身。它只是转发它，直到它离开网络。如果仍然转发原始IP，代理有什么用？只需将其锁定到远程地址，这是唯一安全的选择。即使您要将 x-forwarded-for 标头验证为有效的 IPv4 或 IPv6 地址，它仍可能包含任意 IP。
在该页面上的示例代码下方，他们确实想到了本地 IP 和 IPv6（即使 IPv6 示例包含无效地址）：
请记住，在本地环境中，不会返回有效 IP，通常可能会弹出字符串 :::1 或 :::127，从而调整您的 IP 检查逻辑。
但他们也应该考虑到标头可以包含任意数据。很好的发现！
由于它是一个 wiki，我想任何有帐户的人都可以编辑该页面。如果没有，您应该联系他们。这确实是不好的做法，许多人甚至可能将未$IP转义的内容插入数据库。通常不可能欺骗 REMOTE_ADDR 环境变量，因此在正常情况下它应该是安全的（尽管即使是这种情况我也不会将其插入未转义的情况下），但是 X-forwarded-for 标头在这里破坏了它。
此代码是一种安全控制，因此，必须针对其要控制的威胁对其进行评估。在这种情况下，不会根据 IP 地址授予特殊访问权限。相反，IP 地址被用作对已经很强大的授权机制（HTTP Cookies）的附加约束。
攻击者确实可以通过 X-Forwarded-For 标头欺骗用户的 IP 并绕过此额外检查，但这意味着攻击者不仅必须知道用户的会话 ID (cookie)，还必须知道用户的 IP 地址。这使得利用会话窃取 XSS 变得更加困难。
考虑一下可以实现此控制的其他方式。首先，如果控制根本没有到位，那么任何会话窃取攻击（XSS、流量嗅探、SSL MITM 等）都会为攻击者带来完全可用的会话，而无需额外工作。
相反，如果控制是在没有咨询 X-Forwarded-For 标头而仅咨询 HTTP_REMOTE_ADDR 的情况下实现的，那么位于同一代理后面（例如在学校或企业中）的攻击者将不需要任何有关该控制或用户的内部 IP 具有完全可用的会话，因为所有传出 HTTP 会话似乎都来自同一个 IP（代理的 IP）。
通过添加对 X-Forwarded-For 的检查，该控件要求攻击者了解用户的 IP 地址，并且能够在 X-Forwarded-For 标头中进行欺骗（并非每个攻击者都完全不受约束，因此存在降低风险。不是消除风险，因为我们必须假设存在一些不受约束的攻击者。）
一种可能加强这种控制的方法是保留一些额外的信息：最后使用的 IP 地址的来源。例如，如果会话首先被授予并与来自 HTTP_REMOTE_ADDR 的 IP 相关联，则控件可能要求该会话上的未来流量必须来自从 HTTP_REMOTE_ADDR 收集的 IP，而不是 X-Forwarded-For。这消除了一些欺骗的机会。反向实现检查的好处（更喜欢 X-Forwarded-For 而不是 HTTP_REMOTE_ADDR）可能不值得付出努力，因为欺骗真实的网络地址比 HTTP 标头更难。