When you have a group of front-end termination points in a pool, proxying requests off to hundreds of machines for thousands of applications, tying a session to any IP is a headache. IMO, sessions are supposed to be tied to users, not any given inbound IP that can, and may, jump between different routers, proxies, NAT hosts, etc.
-Ronabop On Mon, Sep 23, 2013 at 7:29 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: > Hi all, > > There isn't any good counter measure session hijack. > However, we can regenerate session ID if IP address has changed. > Hijacked users might notice that they have been logged out if session > ID is regenerated by attackers. Therefore, users have slight chance > to notice that they were under attack. It's not greatly effective, but > better than nothing. > > Although this can be implemented in user script, it would be better if > session module supports this behavior. Better security by default > is good thing. It requires INI, since some apps may assume session > ID would not change. > (I do not encourage to use session ID for CSRF protection, but > there are such implementations, for example.) > > A concern is that there are growing number of browsers share > state. I do not research these browsers behavior yet. I suppose > session cookie (expire=0) would not be shared. > > Anyone has any comments on this? > > Regards, > > -- > Yasuo Ohgaki > yohg...@ohgaki.net >
