There are a lot of questions on StackOverflow relating to session security / session hijacking, but there doesn't seem to be a really good solution to the problem. The three most common suggestions are as follows:
Track the users IP address as part of their $_SESSION data, and possibly invalidate a session if it changes. The downside is that lots of users have dynamic IP addresses, so you risk invalidating a user seemingly at random (their perspective).
Same as 1., but using a User Agent. Two issues here: there may not be a UA to track, and they can change during browser upgrades, etc.
Second cookie, with a unique token. The problem here is that if an attacker gets a hold on the normal session cookie, they're very likely to be able to get a hold on your secondary token as well.
So, with these three options it seems that IP address is the best option, since you're guaranteed to be passed one and its independent of physical security (and if the user is physically compromised, you lose regardless). With that in mind, I have a couple questions relating to IP address changes:
How often would a users IP address really change under normal conditions. I have DSL at home, with the usual dynamic IP concerns, and according to gmail my IP hasn't changed in days. AFAIK, this only really happens when the modem cycles anyway, right? That seems like a rare enough event that it might be ok to invalidate the session.
I think I remember Jeff saying in one of the SO podcasts that they did something similar, though it was possibly for something else. The idea was that using the first two (I believe) octets of an IP address could be considered "close enough" in some circumstances. This allows a user to move around on the same ISP, but the system would notice if the user was suddenly in another ISPs range. Is this a viable tactic?