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

Hi Stas, On Fri, Feb 14, 2014 at 5:22 PM, Stas Malyshev <smalyshev@sugarcrm.com>wrote: > > 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. > > If anything was called that makes old session invalid, any further > access to this session should result in failure. How the app does it, > does not matter really. Doing otherwise would be a huge security problem > - you removed the session, but you still can access it. Timing does not > matter - milliseconds of unauthorized access may be enough to compromise > an account. So I don't see any use in "delete, but only with delay" > option - if the data still valid, no reason to delete, if not valid - > should be deleted immediately. Ideally, it is better to be deleted immediately. Due to the limitation of web technology, it is not possible without unwanted behaviors. - Limitation: It is impossible to force browsers access resources one by one. - Unwanted behaviors: Some accesses may be denied, image/iframe/js content/etc not accessible by vanished session. As I explained, current work round for the limitation (keep "must be deleted" session) allows access to attackers indefinite period of time. It will be reduced from indefinite to seconds with this RFC. When ideal solution cannot be chosen, we should choose better. Allow attackers seconds or indefinite attack time? Users may set as short as 1 second with this RFC. Implementation/setting of delayed deletion is debatable, but choice is obvious to me... Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net