Hi all, Current session module manages session data lazy manner.
session_regenerate_id() does not delete old session data and leave it accessible undefined period. i.e. It survives as long as it's accessed before expiration time. This is security threat when attacker steal session ID. session_regenerate_id() has option to delete old session data. session_regenerate_id(TRUE) deletes old session data, but this option is disabled by default since it causes race condition. i.e. User may get empty session. I would like to propose more strict session data management when session.use_strict_mode=On or enabled always. (BTW, I'm willing to remove use_strict_mode, enable it always) 1. Enable old session data deletion for session_regenerate_id(). 2. When session data is deleted, add "hidden" deletion timestamp to $_SESSION. 3. When to be deleted session data is loaded, session module checks if it is accessible by comparing "hidden" timestamp in $_SESSION. If it is accessible, session module initializes session without "hidden" timestamp. If it is not accessible, session module actually deletes the session data and create new session. The "hidden" session deletion timestamp may be implemented as $_SESSION['__SESSION__DESTROY__'.session_id()] = time() + 60; Session module creates "'__SESSION__DESTROY__'.session_id()" automatically upon session_regenerate_id() call. With this behavior, session module *always* deletes obsolete session data. The reason that rather long delay is needed is wireless networks. Wireless network is unstable and may have very long delay. e.g. Imagine you're in a elevator. 60 seconds may be too short for some applications. Therefore, there will be "session.destroy = 60" INI setting. It is also good to have means to notify obsolete session data access to script. session_status() will have new destroyed status. As I described already, current session management is lazy to delete obsolete session data. New behavior is much stricter than now and there is no exposed internal data to users(script). The "hidden" timestamp only exists in obsolete session data. New behavior requires less GC also. Comments are appreciated. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net