On Tue, Sep 24, 2013 at 4:29 AM, 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 > 1, as you said this regeneration is not feasible for everyone: in some setups the client remote address not available to php, or through another environment variable, in other cases the client uses some kind of proxy or tunnel (tor comes to mind) which causes the source ip to change between requests, and there are also some ISPs who are doing stuff like agressive NATing or giving out public IPs through DHCP but with really short lease times, so the clients are changing IPs frequently. 2, this can be implemented in userland, either in the application bootstrap, or writing a custom session handler( http://php.net/manual/en/class.sessionhandler.php). 3, it seems that there is an agreement that introducing language level INI switches are a bad thing. if we add this, frameworks/apps/etc. which don't want this feature (because they don't need it, or they have a better implementation already) would be in a bad spot, because they would either write some code to detect and circumwent this, or they would have to educate their users to disable this feature in their installation, which can be a hard thing to do, as many sites are running on shared hosts, where doing configuration changes are hard even more when you are requesting to disable a "security feature". so to summarize: personally I'm not convinced that this would be useful for most of the php users, as client IPs changing to frequently to be not cumbersome for the users to lose their sessions, but this could definitely break some sites on the internet (php installations behind proxies/load balancers not passing the original client in in REMOTE_ADDR), and this would also require countermeasures from the framework/apps/etc. which makes me vote a -1 on this proposed feature. maybe this could be shipped as a non-default SessionHandler implementation, and reuse the current session handler infrastructure and config ini. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
