Re: [VOTE] RFC: Introduce session_start() options - read_only, unsafe_lock, lazy_write and lazy_destroy

Hi Stas, On Thu, Feb 13, 2014 at 12:39 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote: > I almost forgot to start vote for this RFC. > This RFC is to introduce options to session_start(). > Options are read_only, lazy_write, unsafe_lock and lazy_destroy. > lazy_destroy is bug fix in fact. > I think there is some misunderstanding. lazy_destroy is design bug fix indeed. Without it, we cannot make sure that old sessions are deleted when session_regenerate_id() is called, or unwanted race condition if it is deleted. Leaving old session alive works, but it opens attack vector unnecessarily. I thought "deleted session data should be deleted" like you at first. You can see that in this thread. http://marc.info/?l=php-internals&m=138242492914526&w=2 However, conclusion is "Session data cannot be deleted immediately". Accesses from a client are not serialized. Therefore, immediate session data deletion results in unwanted behavior. Application that manages personal photos is good example. - User can only display photos when he/she is logged in. - There are private photos in user's personal page. i.e. All photos are protected by authenticated session. When browser accesses to the personal page, application checks authentication status and returns HTML page for it if user's session is authenticated. Browser tries to load images which require authenticated session. If session_regenerate_id() is called (timeout, etc) while loading images, what happens? If old session data is deleted, other images cannot be loaded because requests are done by old session ID. This scenario valid since current browser uses multiple connections to load resources of a web page. Currently, session_regenerate_id() does not delete session by default. It leaves old one. It is made not to delete old session data by default so that it will work under such scenario. What happens to "should be deleted" old session data? It keeps working as valid session until it is deleted by GC. This behavior is not acceptable. If user's session is stolen by JavaScript injection/sniffering/etc, attacker may abuse stolen session forever. All attacker has to do is access web server so that GC will not delete it. session_regenerate_id() does not help because attacker has valid authenticated session already. The solution for this is delayed deletion when session should be deleted. lazy_destroy (name could be changed) allows to access deleted session data specified amount of time. No more than that. (90 sec by default). Therefore, attackers cannot abuse stolen sessions forever and session_regenerate_id() works as it should. i.e. Create new session and delete old one to mitigate risk of stolen session. By the way, session_destroy() could be made to delete session data immediately. It is made not to delete immediately to keep consistent destroy behavior with session_regenerate_id(). Unless user use session_destroy() strange way, immediate deletion should not be a problem. I hope I explained well enough to understand what is the session_regenerate_id() bug. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net