Re: [RFC] [Discussion] Secure session_regenerate_id()

From: Date: Thu, 20 Mar 2014 09:19:49 +0000
Subject: Re: [RFC] [Discussion] Secure session_regenerate_id()
References: 1 2 3 4 5 6 7 8  Groups: php.internals 
Request: Send a blank email to internals+get-73328@lists.php.net to get a copy of this message
Hi Mateusz, On Thu, Mar 20, 2014 at 6:13 PM, Mateusz Kocielski <shm@digitalsun.pl>wrote: > On Thu, Mar 20, 2014 at 05:30:36PM +0900, Yasuo Ohgaki wrote: > > Hi Mateusz, > > > > On Thu, Mar 20, 2014 at 5:23 PM, Mateusz Kocielski <shm@digitalsun.pl > >wrote: > > > > > > > I agree. But we've got more factors here, it's not a simple tool > for > > > > > detection > > > > > of crimes. If we let "old session" live for x secs, what will > happen to > > > > > changes done to the old session? How do you want to resolve that? > We > > > should > > > > > find a balance between complexity and security. > > > > > > > > > > > > > > Currently we have poor mitigation. My proposal provides better > > > mitigation. > > > > > > I still don't see how you want to handle inconsistency between > sessions. It > > > seems that your RFC silently ignores that issue. > > > > > > I'm not sure which inconsistency. Could you specify/describe it? > > Consider following scenario: > > 1. session_regenerate_id(..) is called > 2. request to /update_session with old session id is done (some key-value > in > session is changed) - with your change this request will succeed > --- from here user uses only new session - > 3. updated key-value is missing in new session > > (same scenario can be triggered now if old session is not deleted) This race condition will not change with or without my proposal. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net

« previous php.internals (#73328) next »