Cakephp/php 用户会话交换我们的一部分客户
有一个我们无法复制的错误，该错误涉及我们企业客户的某一特定区域的用户交换。例如，用户在登录页面上以自己的身份登录，当到达家时，他们是另一个用户。
看起来像是意外的会话劫持，线索如下：
- cakephp 安全性设置为低（这仅意味着 cookie 不 重写每个页面加载，并且cookie不做用户代理 检查）
- 我们的cookie设置为不关心子域（.example.com而不是example.com）
- 企业用户如果登录到错误的区域，则会使用302重定向（我们应该使用303吗？）
- 有一个301意外发送出去，但用户能够将
- 所有受影响的用户复制到单个路由器后面，通过 Sprint MPLS 共享互联网。
- 所有受影响的用户可能正在使用客户发布的计算机
- ，他们的 IT 声称没有代理缓存，也没有远程 VPN 访问，但他们声称能够从家庭计算机和网络之外复制该问题。
由于我们无法以任何方式复制该问题，因此我们只能假设该问题特定于他们的网络。
我们如何证明他们的网络/计算机导致了会话交换？或者，当没有其他用户遇到此问题时，我们端的什么配置可能会导致此问题？
[编辑/更新]
响应评论提供的某些方向 - 我们的流量不足以发送重复的 ID。 （统计概率太低，无法看到我们看到客户复制的内容）。
另请参阅：
更新：
我们使用FCGI，显然需要mod_php来理解x_forwarded_for
There's a bug, which we can not replicate, which involves users in one specific region of our enterprise customers swapping. For example, a user logs in as themselves on the login page, and when arriving at the home, they are another user.
It seems like accidental session hijacking, here are the clues:
- cakephp security is set to low (this only means the cookie doesn't
rewrite every page load, and the the cookie does not do a user agent
check ) - our cookie is set to not care about subdomains (.example.com instead of example.com)
- enterprises users areredirected using a 302 if they login to the wrong area (should we use 303?)
- there was a 301 accidentally sent out, but users are able to replicate
- all the affected users are behind a single router, sharing internet via Sprint MPLS
- all the affected users may be using computers issued by the customer
- their IT claim there is no proxy cache, and no remote VPN access, yet they claim to be able to replicate the issue from home computers and off the network.
Since we can not replicate the issue in any way, we can only assume that the issue is specific to their network.
How can we prove that their network/computers are causing the session swapping? Or, what configuration on our end could be causing this, when no other users experience this issue?
[edits/updates]
Responding to some direction provided by comment - our traffic is not large enough to send duplicate IDs. (the statistically probability is too low to see what we've seen the customer replicate ).
see also:
- Zend Framework Session swapping issue
- why is php generating the same session ids everytime in test environment (WAMP)?
Update:
We use FCGI, and apparrently mod_php is required to understand x_forwarded_for
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这可能是注销时会话失效不当造成的问题。请确保会话中的所有变量都正确终止，或者显式 null 终止会话中的每个对象，然后使会话无效。
第二个原因可能是在代码中使用变量检查静态变量。静态变量使用不当也可能导致此间歇性问题。
使用记录器记录映射到用户 ID 的会话 ID，这可以缩小问题范围并帮助您了解到底发生了什么。
在登录操作中使现有会话无效并创建新会话并将内容复制到新会话将有很大帮助。
This may be a problem with improper session invalidation in the log out. please ensure that all the variables in the session are properly terminated or explicitly null terminate every object in the session and then invalidate the session.
The second reason may be the use of variables check for static variables in your code. improper use of static variables may also cause this intermittent issue.
Use logger to log session id mapped to the user ids that can narrow down your problem and help you understand what exactly happening.
Invalidating the existing session in login action and creating a new session and copying content to the new session will help a lot.
首先，不要假设客户有错。这可能是他们或你的问题。在测试之前不要做出任何假设。
不管是谁的错，你都有责任去解决或帮助解决它。
首先，一个用户变成另一个用户通常是会话 ID 问题造成的。您在 Cake 中设置的安全级别不会为每个请求重新生成会话 ID。
我首先将
$session->id()作为本地网络内部和外部的用户进行记录。然后比较会话 ID 是否相同或是否为空字符串。解决此问题的一种方法是为每个用户生成唯一的 ID。如果每个实例的会话 ID 都是唯一的，您可能需要在负载下测试它。
重点是首先进行测试并根据发现得出结论，而不是猜测。
First, do not assume the customer is at fault. It may an issue on their side or yours. Do not make an assumption as to which before testing.
Regardless of who's fault it is, the burden is on you to fix or help fix it.
First, having one user become another is often the result of a Session ID problem. The security level you have set in Cake does not regenerate the Session ID for every request.
I would start by logging the
$session->id()as a user both inside and outside your local network. Then compare to see if the session id is ever the same or ever an empty string. One fix for this is to generate a unique id for each user.If the Session ID is unique for each instance, you may want to test it under load.
The point is to test first and make conclusions based upon findings, not speculation.