防止会话劫持

Question

如何防止多个客户端使用相同的会话ID？我问这个是因为我想添加额外的安全层来防止我网站上的会话劫持.如果黑客以某种方式计算出另一个用户的会话ID并使用该SID发出请求,我如何检测到服务器上有不同的客户端共享一个SID然后拒绝劫持尝试？

编辑

我仔细考虑后接受了Gumbo的回答,因为我已经意识到由于无状态HTTP协议的限制,我所要求的是不可能的.我忘记了什么可能是HTTP的最基本原则,现在我认为这个问题似乎有点微不足道.

让我详细说明我的意思:

在用户A登录example.com后,他会获得一些随机会话ID,为简单起见,让它为'abc123'.此会话ID在客户端存储为cookie,并通过服务器端会话进行验证,以确保登录的用户在从一个网页移动到另一个网页时仍然登录.如果HTTP不是无状态的,那么当然不需要存在这个cookie.因此,如果用户B窃取用户A的SID,并在其计算机上创建一个值为'abc123'的cookie,他就会成功劫持用户A的会话,但服务器根本无法合法地识别用户B的请求与用户A的请求有任何不同,因此服务器没有理由拒绝任何请求.即使我们要列出已经在服务器上处于活动状态的会话并尝试查看是否有人正在访问已经处于活动状态的会话,我们如何确定它是另一个非法访问会话的用户而不是同一个用户谁已经使用会话ID登录,但只是尝试用它发出另一个请求(即导航到不同的网页).我们做不到.检查用户代理？可以欺骗 - 尽管如此,作为深度防御措施还是很好的.IP地址？可以出于正当理由进行更改 - 但是我没有根本不检查IP地址,我建议检查IP的前两个八位字节,甚至是数据计划网络上的用户,因为完全合法的原因,他们经常拥有不断变化的IP通常只有IP更改的最后两个八位字节.

总而言之,正是无状态HTTP谴责我们永远无法完全保护我们的网站免受会话劫持,但良好的做法(如Gumbo提供的那些)将足以防止大多数会话攻击.因此,试图通过拒绝同一SID的多个请求来保护会话免受劫持是荒谬的,并且会破坏会话的整个目的.

Answer 1

遗憾的是,没有有效的方法可以明确地识别出来自与真实请求相反的攻击者的请求.因为大多数反对措施检查的属性(如IP地址或用户代理特征)要么不可靠(IP地址可能在多个请求之间发生变化),要么可以轻松伪造(例如用户代理请求标头),因此可能产生不必要的误报(即真正的用户交换IP地址)或漏报(即攻击者能够使用相同的User-Agent成功伪造请求).

这就是为什么防止会话劫持的最佳方法是确保攻击者无法找到其他用户的会话ID.这意味着您应该设计应用程序及其会话管理:(1)攻击者无法通过使用足够的熵来猜测有效的会话ID,以及(2)攻击者没有其他方法可以通过已知攻击获取有效的会话ID/vulerabilities喜欢嗅探网络通信,跨站点脚本,通过Referer泄漏等.

那就是说,你应该:

• 使用足够的随机输入来生成会话ID(请参阅session.entropy_file,session.entropy_length和session.hash_function)
• 使用HTTPS在传输过程中保护会话ID
• 将会话ID存储在cookie中,而不是存储在URL中,以避免通过Referer泄漏(请参阅session.use_only_cookies)
• 使用HttpOnly和Secure属性设置cookie 以禁止通过JavaScript访问(如果是XSS漏洞)并禁止通过不安全通道进行传输(请参阅session.cookie_httponly和session.cookie_secure)

除此之外,您还应该在某些会话状态更改(例如,登录后确认真实性或更改授权/权限)之后重新生成会话ID,同时使旧会话ID无效(请参阅session_regenerate_id功能),您还可以定期执行此操作以缩短时间范围成功的会话劫持攻击.

Answer 2

我们能不能做这样的事情。

将会话 ID 存储在数据库中。还要存储该会话 ID 的 IP 地址和 HTTP_USER_AGENT。现在，当请求到达包含该匹配会话 ID 的服务器时，请在脚本中检查它来自哪个代理和 IP。

可以通过为会话创建通用函数或类来使此基础工作，以便在处理每个请求之前对其进行验证。几乎不需要几微秒。但是，如果许多用户正在访问您的站点并且您拥有庞大的会话数据库，那么这可能不是性能问题。但是，与其他方法（例如 => 使用重新生成会话）相比，它肯定会非常安全。

在重新生成会话 ID 时，会话劫持的可能性再次很小。

假设，用户的会话 ID 被复制，并且该用户在一段时间内不工作或不活动，并且没有向具有旧会话 ID 的服务器发出要求重新生成新会话 ID 的请求。然后，如果会话 ID 被劫持，黑客将使用该会话 ID 并使用该 ID 向服务器发出请求，然后服务器将使用重新生成的会话 ID 进行响应，以便黑客可以继续使用这些服务。实际用户将不再能够操作，因为他不知道重新生成的 id 是什么，以及请求中传递的请求会话 id 是什么。完全消失了。

如果我在某处错了，请纠正我。