Cakephp / php用户会话交换我们客户的一部分

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:

Update:

We use FCGI, and apparrently mod_php is required to understand x_forwarded_for

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.

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.