保护 Cookie 和会话
我遇到的问题（可能无法解决）如下：
我的客户是一个大型组织，在 7-8 个不同地点拥有 1,500 多名用户。该应用程序是基于 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 补丁 mod_ssl/2.2.9 OpenSSL/0.9.8g
已知浏览器：IE 8 和 .8g 9、Firefox（操作系统和 Win）和 Safari（操作系统）
The issue I'm having, which may not be solvable, is as follows:
I have a client that is a large organization of 1,500+ users at 7-8 different locations. The application is a PHP application build on the Kohana v3.0 framework. The organization sits behind a proxy filtering server at the ISP level. Each location has one main public IP address that funnels through the proxy then to the web. Each user has a Mac or Windows workstation issued by the employer.
What they are experiencing appears to be cookie collisions. Example: One user logs in at their workstation then another user logs in from the same location, different workstation, with the same OS and browser type. The second user receives the first users' active session by receiving a newly generated cookie (token) that matches the first user. This appears to only be related to the 'authautologin' cookie (set when the remember me check-box is engaged on the login screen), but I'm keeping my options open to caching from the proxy (I can't prove that the proxy is caching yet).
Because of the network setup, the server sees hundreds of users logging in from the same IP address with the same user agent. My initial thought is that the Kohana v3's way of generating cookies that are unique to the browser (user agent) is not unique enough for this real-world application.
Has anyone ever experienced anything like this? And what would be the proper actions to take in cookie and session generation? Would managing cookies and active sessions in the database be better?
Kohana Modules: Jelly-Auth, Jelly, and Auth
Server: Apache/2.2.9 (Debian) mod_fastcgi/2.4.6 mod_jk/1.2.26 PHP/5.2.6-1+lenny8 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g
Known Browsers: IE 8 & 9, Firefox (OS and Win), and Safari (OS)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这只是一个想法，但 PHP 会话存在/曾经存在（取决于您的 Debian 和 PHP 版本）错误。我建议您尝试：
It's just an idea but there is / used to be (depending on your Debian and PHP version) a bug with PHP sessions. What I suggest you to try:
哇，这是一个令人讨厌的漏洞，很好的捕获！
到目前为止，在 PHP 下生成 cookie 的最佳方法是让 PHP 来做：
session_start()。仅此而已！如果你生成自己的cookie，那么你确实在某个地方搞砸了。现在您可以使用$_SESSION[]超级全局。最佳实践是在应用程序中访问 $_SESSION 之前在公共头文件中调用session_start()。您可能还应该考虑其他问题，例如 owasp a9， csrf，以及 cookie 标志：
HTTP_Only，以及“secure”标志（强制 cookie 通过 https）。Wow thats a nasty vulnerability, good catch!
By far the best way to generate cookies under PHP is to let PHP do it:
session_start(). And thats all! If you are generating your own cookie, then you really messed up somewhere. Now you can use the$_SESSION[]super global. The best practice is to callsession_start()in a common header file before you access $_SESSION in your application.There are probably other problems you should take into consideration such as owasp a9, csrf, and the cookie flags:
HTTP_Only, and the "secure" flag (forcing the cookie over https).我不确定我是否正确理解了您的意思，但是...我理解请求是这样的：
用户（工作站）==>代理()==>互联网==>公司网站（以及反向响应）。
检查代理是否设置“HTTP_X_FORWARDED_FOR”（在 $_SERVER 超全局变量中）。它可能是确定用户工作站 IP 地址的唯一方法。如果是这样，你就完成了。
I'm not sure if I understood you correctly, but... I understood that request goes like this:
user (workstation) ==> proxy () ==> internet ==> company website (and response in reverse direction).
Check if proxy sets "HTTP_X_FORWARDED_FOR" (in $_SERVER superglobal variable). It could be the only way to determine user's workstation IP address. If so, you're done.