[RFC][VOTE] Enable session.use_strict_mode by default View as Markdown

Hi!

The vote will end in 2 hours and 2 more in favor is required to pass at least.

I don't know the reason why some of us against this RFC, but vote is
the vote. My guess is you prefer more precise timestamp based session
managed which has declined.

The number of votes (7) suggests most people either don't care or don't
understand the issue enough to vote.

Note that default is not necessary to run a secure setup, strictly
speaking - you can always recommend using non-default setting. It'd be
useful to hear from people voting "no" of course.

Stas Malyshev
smalyshev@gmail.com

Hi Bishop,

To decide next move, I would like to start hearing the reason why from
those who are against this RFC.

I abstained from voting. While I would be a "Yes" in principle, two specific
statements in the RFC made me wary of following that instinct:

1. "external session data storage may have noticeable impact"
2. "lost sessions are far better than stolen sessions"

I can hand waive the first one away, as performance can be optimized
usually. But I can't really agree that, in general, lost sessions are "far
better" than stolen ones: if lost sessions happen 1% of the time, and stolen
sessions happen .001% of the time, then to me lost sessions are worse.

Thank you for feedback!

1. This overhead could be avoided. I'll add this to my task list.
2. This could be avoided by timestamp based session management.

Lost sessions could happen:

• When session_regenerate_id(true) which deletes old session data immediately.
  by:
  a. Race condition in browser by multiple requests. (Result in empty session ID)
  b. Race condition between server and browser by multiple requests.
  (Result in empty session data)
  c. Unstable network connection. (Server use new session ID, but
  browser didn't get new ID. Result in empty session data)

It is advised to change session ID periodically. Obsolete(old) session data
should be deleted. i.e. Simply calling session_regenerate_id() is
not good enough because delete flag is false by default. However
immediate removal causes above races. Therefore, short TTL for
obsolete session is required.

Chance of c. does not change regardless of session.use_strict_mode.

session.use_strict_mode=1 increases chance of a. and b. because session
module will try to set new session ID many times. e.g. Session could be
expired while browser is loading resources. It uses multiple connections for
access to images, css, js, etc. These resources could be using session for
access control, customization, etc and result in many set-cookie headers
for session. i.e. many set-cookies more chances for races.

session.use_strict_mode=0 uses supplied old session ID and less likely to
have race. i.e. No set-cookie headers are sent for new session ID.

I cannot mention specific probability change. Hopefully, it would not
be too much.
(I don't like this, so I proposed timestamp based session management RFC)

If session module removes old session data a little after
session_regenerate_id() is called, chances to have races will not increase.

This could be done by user script also. It might be an off topic, but FYI.

PHP 5.x and 7.x
--- Set TTL before regenerate and save ---
$_SESSION['TTL'] = time() + 300;
session_commit();
session_start();
session_regenerate_id(); // It simply generates and sets new session ID.
unset($_SESSION['TTL');

PHP 7.x only. More efficient.
--- Set TTL before regenerate and save ---
$_SESSION['TTL'] = time() + 300;
session_regenerate_id(); // It writes and closes old session data and
// creates new session data since 7.0
unset($_SESSION['TTL'])

And check TTL value where normal session_start() is called and destroy
when it is expired.

My other declined RFC does this for users automatically (no code at all)
as well as other convenient things.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net