确保Cookie和会话安全

Question

我遇到的问题可能无法解决，如下：

我的客户是一个拥有1,500多名用户的大型组织，分布在7-8个不同的位置。该应用程序是一个基于Kohana v3.0框架的PHP应用程序。该组织位于ISP级别的代理筛选服务器后面。每个位置都有一个主要的公共IP地址，通过代理然后流入网络。每个用户都有一个由雇主签发的Mac或Windows工作站。

他们遇到的似乎是cookie碰撞。示例：一个用户在其工作站登录，然后另一个用户从相同的位置，不同的工作站登录，具有相同的操作系统和浏览器类型。第二用户通过接收与第一用户匹配的新生成的cookie（令牌）来接收第一用户的活动会话。这似乎只与'authautologin'cookie（在登录屏幕上记住我的复选框时设置）有关，但我保持我的选项对代理缓存（我不能证明代理正在缓存）。

由于网络设置，服务器会看到数百名用户使用相同的用户代理从同一IP地址登录。我最初的想法是，Kohana v3生成浏览器（用户代理）独有的cookie的方式对于这个真实世界的应用程序来说不够独特。

有没有人经历过这样的事情？什么是在cookie和会话生成中采取的适当行动？管理数据库中的cookie和活动会话会更好吗？

• Kohana模块：Jelly-Auth，Jelly和Auth

• 服务器：Apache / 2.2.9（Debian）mod_fastcgi / 2.4.6 mod_jk / 1.2.26 PHP / 5.2.6-1 + lenny8与Suhosin-Patch mod_ssl / 2.2.9 OpenSSL / 0.9.8g < / p>

• 已知的浏览器：IE 8＆amp; 9，Firefox（OS和Win）和Safari（OS）

Answer 1

哇，这是一个令人讨厌的漏洞，很好的捕获！

到目前为止，在PHP下生成cookie的最佳方法是让PHP执行： session_start()。就这样！如果你正在生成自己的cookie，那么你真的搞砸了。现在您可以使用$_SESSION[]超级全局。最佳做法是在应用程序中访问$ _SESSION之前在公共头文件中调用session_start()。

您可能需要考虑其他问题，例如owasp a9，csrf和Cookie标记：HTTP_Only以及“安全”标记（通过https强制cookie）。

Answer 2

这只是一个想法，但有/曾经（取决于您的Debian和PHP版本）PHP会话的错误。我建议你尝试一下：

1. 检查this link - 这可能与您的问题无关，但值得一试
2. 切换到数据库驱动程序 - 我有90％的可能会解决所有问题
3. 在不同的Debian服务器上进行测试 - 虽然这可能不容易实现

Answer 3

我不确定我是否理解正确，但是......我明白请求是这样的：

用户（工作站）==＆gt; proxy（）==＆gt;互联网==＆gt;公司网站（反向反应）。

检查代理是否设置“HTTP_X_FORWARDED_FOR”（在$ _SERVER超全局变量中）。它可能是确定用户工作站IP地址的唯一方法。如果是这样，你就完成了。