This RFC is renamed. Refer to the latest
https://wiki.php.net/rfc/precise_session_management
Keeping HTTP session as secure as possible is what the session manager's task. Session manager can improve HTTP session security without user code modification while keeping compatibility with existing applications. Please note that this RFC is for session manager behavior.
session_regenerate_id() is used to generate new session ID. It's better to delete old session data to reduce risk of session hijack. However, session_regenerate_id() leave old session data by default currently. (i.e. session_regenerate_id(FALSE) is the default) Old session data is active and usable until GC.
Old session is left active for reliable session ID regeneration. There are many reasons why old session is left. Examples are:
For reliable session ID regeneration, only short periods (few seconds for wired connections, few minutes for mobile connection) is enough.
Leaving old session opens window to attacker widely:
Counter measure for session hijack: Requirement - Session ID regeneration must be reliable.
Problem of immediate old session deletion:
“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.
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.
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.
Above attack can be done by existing tools. i.e. Script kiddies' task.
If you are curious, search YouTube or net.
Even if there is only recent bug report for this, this bug is known more than 10 years since when session_regenerate_id() is introduced.
Add 'session_destory_ttl' INI directive(INI_ALL, default 300 seconds) and “make sure old session is deleted certain period”.
This can be achieved by time stamp in session data. When session_regenerate_id()/session_destroy() is called without parameter, session manager sets
$_SESSION['__SESSION_DESTORY_TTL__'] = time() + ini_get('session.regenerate_id_expire');
for old session data. This is pseudocode. User will never see $_SESSION['SESSION_DESTORY_TTL'] as it is removed/added upon session data serialization internally in session module.
$_SESSION['__SESSION_DESTORY_TTL__'] also stores new session ID when TTL is set by session_regenerate_id().
integer_string_timestamp\0string_session_id
If browser accesses to be deleted session (old session), session module uses new session ID rather than old and try to set correct new ID. i.e. Send new session ID cookie to browser. This prevents lost session under unstable network.
If session module finds $_SESSION['__SESSION_DESTORY_TTL__'] and timestamp is old, delete old session data and create new session with new session ID. E_WARNING error is raised for this because it means either too short TTL or user is under attack.
When session_regenerate_id(true)/session_destroy(true) is called, session module destroy session data immediately.
Users may add $_SESSION['__SESSION_DESTORY_TTL__']. When this is happen, session module raise E_WARNING for this.
Session data may be lost when network connection is unstable. For example, when user ender elevator or subway connection can be lost in a way that session data is lost. 300 seconds would be enough for most elevators. However, it may not be enough for subways. PHP developer may require longer TTL for better stability.
Some PHP developers may want to be more strict and need shorter TTL even if it could result in lost session on occasions. They may set 30 seconds TTL which would be long enough for stable connection in most cases.
Currently, users must call session_regenerate_id() without destroy flag to have stable session. Therefore, old session data is valid as long as it is accessed even if it should be discarded as invalid session. Attackers can take advantage of this behavior to keep stolen session forever.
PHP 7.0
If there are any php.ini settings then list:
Make sure there are no open issues when the vote starts!
Other than session management, there is no affected functionality.
Session expire and GC can be improved by time stamp also.
TBD