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)
- Enable old session data deletion for
session_regenerate_id(). - When session data is deleted, add "hidden" deletion timestamp
to $_SESSION. - 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
yohgaki@ohgaki.net
Hi all,
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.
Current session manager is lazy for expiration also. The same method,
"hidden"
timestamp, can be used for housekeeping.
If the timestamp is updated always, "lazy_write" option is spoiled. To
prevent that,
last modified time updates could be done with longer resolution, i.e.
Update timestamp
by every minute, not second.
With this, GC is only need for true GC. i.e. GC will not be used to expire
session data.
Therefore, GC may be done once a day, for example.
Any comment?
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi all,
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.Current session manager is lazy for expiration also. The same method,
"hidden"
timestamp, can be used for housekeeping.If the timestamp is updated always, "lazy_write" option is spoiled. To
prevent that,
last modified time updates could be done with longer resolution, i.e.
Update timestamp
by every minute, not second.With this, GC is only need for true GC. i.e. GC will not be used to expire
session data.
Therefore, GC may be done once a day, for example.Any comment?
If there aren't comments, I shall start writing a RFC for this in a few
days.
Please comment, if you have.
Thank you.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net