问题标签 [session-hijacking]

目前，我们的产品用户在其内部网络上使用代理时遇到了一些问题。

根据他们的系统管理员的说法，代理对端口 80 和 443 是开放的，并且不会对 cookie 等做任何事情，只会阻止一些网站。

问题：当用户 X 登录到我们的应用程序时，用户 Y 也登录到以前没有使用过应用程序的计算机上（但在同一个代理后面）？！这不应该是可能的（使用 django 默认身份验证应用程序）？

我们使用的是 Apache、Nginx、Django 1.0 和 Postgresql。另请注意，它在使用 runserver 运行时确实有效，但不适用于 nginx。

这只发生在具有代理的用户身上，在其他网络上，它确实有效。

以前有人经历过吗？如果有，你是怎么解决的？

提前致谢！

斯特凡

我最近在这里阅读了一篇关于使 ASP.NET 会话更安全的文章，起初它似乎非常有用。

以前我一直在会话中存储用户的 IP 地址，然后确保在每个后续请求中请求 IP 等于存储的 IP。

文章中的代码还通过检查 IP 地址来保护会话，只是它存储了一个包含用户 IP 的散列消息身份验证代码作为会话 cookie 的一部分。它会为每个请求创建两次哈希 MAC，我想这会减慢速度。

我已经在他们的代码中看到了一个潜在的缺陷：如果你以某种方式获得了用于生成 MAC 的密钥，那么你就可以使用你自己的 IP 生成一个有效的 MAC——你甚至不必伪造 IP会议开始于。

对于一个简单的问题，这似乎是一个过于复杂的解决方案，它不仅会产生更大的开销，而且比简单的方法更容易受到攻击——除非我完全没有抓住重点。

那么，为什么这种方法比我一直使用的更简单的方法更安全呢？

顺便说一句，作者还指出您不应该在比较中使用整个 IP 地址，因为如果某些用户的 IP 在代理后面，则它们会更改每个请求。如果您检查 X_FORWARDED_FOR，情况仍然如此吗？

谢谢！

我使用 python 的 scapy 编写了一个脚本来劫持 TCP 连接。

在测试对几个虚拟机（服务器 - xp_sp3，客户端 - xp_sp1）之间连接的攻击时，我找到了客户端端口，然后是服务器的 SND.NEXT 并使用它的客户端 SND.NEXT （我已经将它们与wireshark进行了比较他们是合法的）。

现在，当使用客户端的 SND.NEXT 从客户端向服务器发送欺骗数据包时，我看到数据包确实到达了服务器，但没有到达 NetCat（它的目的地），而且当我将它与真实的客户端数据包进行比较时它看起来几乎相同（不同的 mac、ttl、窗口大小等）

除了我所做的之外，我还应该做些什么来使数据包对服务器看起来合法？

为了防止会话劫持，我编写了以下三个函数。他们工作。我在脚本开头调用 set_auth_token 。然后在 html 表单中调用 get_auth_token。表格发布后，我调用 check_auth_token。但是，有时在用户填写表格后，如果填写错误，他们往往会按 F5/Refresh。这会导致页面“死亡”。在填写表格之前不会发生这种情况。

我可以做些什么来改进这些，以便他们不会在每次用户按下刷新时死掉？

get_auth_token 总是在 set_auth_token 被调用后被调用，因此如果找不到授权令牌，它就会死掉：

导致页面死机的函数：

干杯。

场景：在我的网站上开始会话后，我生成了一个 rand 令牌，该令牌显示给用户一次。说他们将其“存储”起来以备后用。然后，我将 md5(token) 插入带有时间戳的 SQL 中。当用户访问其他页面（如登录）时，他们必须通过 URL 传递令牌作为验证过程的一部分。我会检查令牌是否存在，并可能更新此令牌的用户 ID。

所以。即使有人窃取了用户的 PHPSESSID cookie，由于他们在不知道令牌的情况下无法访问这些页面中的任何一个，这对黑客来说不会有任何好处吗？

我一直在寻找防止会话劫持的方法，即有人窃取会话 cookie 并使用它来访问系统。

诸如http://codebutler.com/firesheep之类的程序可以很容易地嗅探开放无线网络上的会话，而其他获取会话的方式包括跨站点脚本攻击，或者只是将它们从受害者的计算机中取出。

使用 SSL 保护所有会话 cookie/服务器通信对于防止 Firesheep 嗅探至关重要，并且在 cookie 上设置 HTTPOnly 有助于防止 JavaScript 在 XSS 攻击中读取会话 cookie，但它仍然容易受到基于 AJAX 的攻击。

另一层是在每次请求时更新的会话 cookie 中包含安全令牌或随机数。您将令牌存储在服务器端数据存储区和 cookie 中，并在每个请求中比较 cookie 中的令牌与数据存储区中的令牌匹配。

如果令牌不匹配，则可能表明有人窃取了会话并试图使用它，因此您可以忽略请求或使会话无效并要求用户重新进行身份验证。但是，不匹配的令牌也可能是由于连接缓慢/不稳定造成的。

例如，您可能遇到这样的情况：服务器接收到来自真实用户的请求，更新服务器数据存储中的会话令牌，并使用包含更新令牌的会话 cookie 响应用户。但是由于连接缓慢/不稳定，用户没有收到响应，因此用户仍然拥有旧的会话令牌，而新的会话令牌存储在服务器上。当用户重试请求时，令牌将不匹配。

缓解此问题的一种方法是让服务器保留最后几个令牌的历史记录并检查它们是否匹配，但随后会变成要保留多少令牌的情况，具体取决于连接的脆弱程度或用户的点击满意度如何，服务器可能会在连接恢复之前循环浏览历史记录，并且浏览器会更新用户的会话。

保留令牌历史记录的另一种方法是为每个会话添加时间戳，并检查时间戳是否在某个短的指定范围内，例如 30 秒。如果用户的会话 cookie 时间戳在服务器存储的会话时间戳的 30 秒内，则认为该会话是真实的。

示例伪代码

这避免了保留令牌历史记录——时间戳成为令牌——但攻击者在会话被盗后有 30 秒的机会劫持会话。虽然这是真的，但令牌历史替代方案并没有更好，因为它为攻击者提供了一个可能更长的机会窗口。

检查 IP 地址和用户代理更改的其他方法也存在问题。用户代理很容易被欺骗，如果攻击者能够获取用户的会话，他们可以通过相同的 XSS 代码或其他方式轻松确定用户代理。

如果用户在移动设备上，他们的 IP 地址可能会频繁更改，从而导致许多误报。此外，攻击者可能位于同一公司防火墙之后，因此用户和攻击者的 IP 与外部 Web 服务器相同。

使用时间戳令牌是正确的方法还是有更好的方法？30 秒的缓冲区是否正确？我错过了哪些边缘情况？

对 IPv4 和 IPv6 都适用的“松散”IP 检查以防止会话劫持的最佳方法是什么？我得到了一个数组，它保存了所有用户的 IP 地址以及用户从该地址连接的次数：

现在我是否想做松散的 IP 检查并将其与 $_SERVER['REMOTE_ADDR'] 进行比较。如果用户只从 1 个地址连接，它是否应该假定会话 id 已被劫持。同时，如果用户定期从 82.34.24.* 更改 IP 地址到 82.34.24.* 应该假设一切正常，但如果用户突然从 82.34.33.0 或某个不属于的地址连接如果假设会话劫持，相同的 IP 组地址或以前从未使用过（例如最后 20 个请求）。

实现这一点的最佳方法是什么，使用inet_pton/inet_nton，但是如何呢？

诸如PHP Session Fixation / Hijacking之类的线程以及 Chris Shiflett 之类的一些人建议检查用户代理 ( $_SESSION['HTTP_USER_AGENT']) 以帮助检查会话有效性。一些资源甚至推荐这样的东西：

然而，Chris Snyder说“浏览器代理的世界与用户的世界相比是微不足道的，因此每个用户不可能拥有一个单独的用户代理。此外，欺骗用户代理并不难。而且所以检查这个指标作为会话有效性的证明几乎没有什么实际意义”（第 7 章，第 103 页）。

当遇到相互冲突的建议以及某些建议可能已过时（例如上面的 Shiflett/PHPSec 示例，其时间戳似乎是 2005 年 3 月 18 日星期五）时，很难知道该怎么做。较新的建议，例如 Snyder（发布日期：2010 年 12 月 9 日）的建议似乎更好，但总是这样吗？（例如，尽管花了很多时间推荐使用mysqli，但 Snyder 完全忽略了 Stack Overflow 用户似乎同意的更好选择——PDO所以我并不完全相信 Snyder 是最终值得信赖的专家） .

所以我想我的问题有两个部分，一个是具体的（我应该费心检查用户代理吗？）和一个更笼统的（当谈到 PHP 安全的最新思想时，我应该相信谁的建议？），我的明显偏见是“相信 Stack Overflow 上的人！” ——或者我不会一开始就问，因为众包最新的想法通常是最好的主意。

在@Radu 的评论中进行有用的讨论，以澄清 HTTPS 问题——

Snyder 似乎在说两件事：1.) HTTPS 使其他工具变得不那么必要或不必要。2.) 在无法使用 HTTPS 的情况下，检查用户代理仍然不是很有用（这似乎是他不同意一些可能较旧的建议的地方）。

我正在对 StackOverflow 进行一些关于如何正确设置会话和防止劫持等的研究。我找到了有人在其中一个问题上发布的答案，他提供了以下代码：

当用户登录并且用户名和密码匹配时

检查用户是否已登录，对于受保护的页面：

它似乎工作正常，但我的问题是：这有多安全，这是一个好方法还是我应该尝试其他方法？该帖子没有投票或任何内容，因此不确定它是否好。

另外，不确定如何通过此会话获取有关用户的信息。我需要在数据库中存储任何内容吗？

谢谢！

我是 Web 开发的新手，我阅读了有关 CSRF、XSS 和会话劫持的信息。一种建议的解决方案是简单地使用 anonce来检查请求的有效性。我用 PHP 编写了这个脚本来防止会话劫持。我认为它在精神上类似于重新生成会话 ID，因为标识符或它们的组合（会话 ID 和随机数）在每次请求时都会更改。

这够了吗？我真的不知道我是否能负担得起 SSL，而且我知道这将是会话劫持的一个很好的解决方案，但我希望对这种方法有所了解。我错过了什么吗？