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

On Wed, Mar 19, 2014 at 04:12:54PM +0900, Yasuo Ohgaki wrote: > HI all, > > I think most of concerns for session_regenerate_id() is discussed. > I would like to finish this RFC. > > Following RFC was made to change session_regenerate_id(TRUE) by default. > I was initially tried to remove old session data immediately with this RFC, > but > it turned out we should care about reliability more in real world > environment. > > Secure session_regenerate_id() > https://wiki.php.net/rfc/session_regenerate_id > > The time stamp could be outside of of $_SESSION. It requires BC > modification in > serializer and/or save handler. It would be complex and possibly slower > depend > on implementation. > > I hope it's precise enough and easy to understand idea behind it. > If you have suggestions, it would be appreciated. > Names can be anything, especially. > > If I'm missing something, please let me know. Hi Yasuo, [...] Errors may be raised for either legitimate user or attacker. If error is raised for legitimate user, legitimate user could know they are under attack. (Possibly network is dangerous or app has vulnerability) If error is raised for attacker, attacker could know they might be caught by illegal access. [...] I wonder how many legitimate users will realize they're under attack. For average user it will look like application does weird things (i.e. logout immediately). If network is dangerous or app has vulnerability then we cannot fix the problem - you can't make n-th layer secure if (n-1)-th layer is insecure. [...] Stealing session ID is easy regardless of HTTPS. Attacker can set up fake router by ARP spoofing. Most networks do not have ARP spoofing prevention, even detection. For HTTP, attacker can view session ID simply. For HTTPS, attacker can set up transparent HTTPS stripping proxy and steal session ID. Most users do not care much if they are connecting via HTTPS or not. [...] What if application uses secure attribute on session cookie? We've got already session.cookie_secure setting which seems to solve the issue. I don't see how by introducing your proposal will make situation better. If application allows login and operates as user without HTTPS, then it's not our problem. [...] Problem of immediate old session deletion: Make session ID regeneration unreliable. (Unacceptable) [...] I haven't found single issue in bugs.php.net that session_regenerate_id(TRUE) is a problem to any user. [...] Remove alarm for possible attacks. (No detection = Insecure) Make sure old session is deleted certain period and Raise error/exception for invalid access provides much better security than current way or immediate deletion. [...] What you mean by "No detection = Insecure"? Kind Regrads, Mateusz Kocielski