why not have a new session module? those who want no change for existing applications keep the old one, new projects can use the new one, those who want more security port their code to the new one. e.g. use session2_start(), etc.

If that's going to be the approach (and I find it appealing) then perhaps there should be other things accomplished as part of the new work; e.g., disable the automatic sending of cookie headers and make it explicit. Or wrap all the features in objects. (I don't want to volunteer anyone else for more work, though, and I myself am not competent to implement those ideas.)

--

Paul M. Jones
http://paul-m-jones.com

Hi Thomas,

why not have a new session module? those who want no change for existing applications keep the old one, new projects can use the new one, those who want more security port their code to the new one. e.g. use session2_start(), etc.

If basic session module design has problems, I would write new one.
However, the design is not the problem, but just implementation is not
finished yet. There wouldn't much BC with timestamp. In fact, almost
all apps will work without any problems with timestamped session
management.

I would rather deprecate/remove session_regenerate_id() if timestamped
session management will not be implemented.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Hi!

Please read session_regenerate_id() example #2.

Example #2 Avoiding lost session by session_regenerate_id()

In this example, why you do session_commit() in my_session_start()?
There's no point in writing stale session.

I also see no code that actually removes old sessions - is it by design?

I am also not sure why this code messes with session.use_strict_mode -
which user code is not supposed to do, this should be possible to do
without doing that.

In fact, thinking about it, I think the following can be done relatively
easily: make session_regenerate_id(), if called with false, to put magic
entries into old session that specify a) when it was regenerated and b)
what was the new session ID.

This would allow to implement example #2 in userspace much cleaner, and
if we want to implement it further in session, we could add option to
session_start to do so. But one could also use this data in your own
session system if one wants to do it slightly differently.

This still leaves the question of old sessions, but it's not new as
session_regenerate_id(false) already exists and in general we have GC.

--
Stas Malyshev
smalyshev@gmail.com

http://php.net/manual/en/session.security.php

http://php.net/manual/en/function.session-regenerate-id.php
It looks like those need some polishing. If somebody with native English
volunteers it'd be great, otherwise I'll do it a bit later.

I was about to make the same comment. I'm sure there are some very
important points in here, but it's quite hard to follow. For instance,
the section "Non-Adaptive Session Management" jumps straight in with the
claim that "PHP's session manager is adaptive by default", but never
explains, as far as I can see, what that actually means. There's also
far too many Warning and Note pop-outs on that page - the whole page is
security advice, does it really make sense to colour every other
paragraph pink?

I think a better approach for both the manual and RFCs proposing changes
is to try to summarise the key attacks users need to protect against,
and how to protect against them (as well as some of the trade-offs
involved). Perhaps then an additional summary at the end with the
recommended combination of settings. Use bullet points, summary
sentences, etc.

I've probably got some details wrong here, but just as an example of the
style:

Session Hijacking

Session Hijacking is one of the simplest session-related attacks: an
attacker accesses the website using another user's session. This can
lead to problems such as:

• The attacker impersonating a known user.
• The attacker gaining access to restricted parts of a site.
• The attacker accessing the user's personal details stored on the
  server (e.g. a "My Account" or "My Orders" page)

To protect against session hijacking, you should:

• Restrict the places the session ID appears. For instance, set the
  session manager to use HTTP-only cookies, and no URL rewriting.
• Verify that the same user is accessing the session on each request.
  For instance, store "fingerprint" details such as User Agent and discard
  the session if it changes.
• ...

Session Fixation

Session Fixation is similar to Session Hijacking, but rather than
discovering the user's session ID, the attacker chooses a new session ID
and tricks the application into using that session ID.

... and so on ...

Regards,

--
Rowan Collins
[IMSoP]

Hi Stas,

Timestamp based session management is required to manage session as it
should. I've updated the session manual pages a while a ago to explain
why.

Could you explain what you mean here? "As it should" is kind of broad :)

http://php.net/manual/en/session.security.php
http://php.net/manual/en/function.session-regenerate-id.php

It looks like those need some polishing. If somebody with native English
volunteers it'd be great, otherwise I'll do it a bit later. It'd be also

Thank you. Please revise, but please do it after realizing underlying issues.

nice to avoid claims of "mandatory" and instead just put explanations of
what each option is doing and what is the recommended setting. Nothing
that is controlled by an option is "mandatory" by definition.

Timestamp is mandatory to manage session precisely and securely.
Current session management is not precise/secure as it does not
control session data expiration and splitted session. i.e. It does not
do anything for legitimate and malicious user's session when there is
hijack attack.

Mandatoriness of timestamp based session management is obvious to me.
If you have question, I'll try to explain why.

I also see http://php.net/manual/en/function.session-regenerate-id.php
"warning" which I assume was added by you claims "Immediate session data
deletion disables session hijack attack detection and prevention also."

• I do not think this is accurate. Or at least it's not clear enough if
  I can't properly understand what it means :)

OK. I'm not sure how to improve

"Immediate session data deletion disables session hijack attack
detection and prevention also."

If session data removed immediately, not only it causes client/network
races, but also make session hijack detection impossible.

BTW, current implementation does not do anything when a session is
splitted into 2 sessions, i.e. legitimate and cracker session due to
session hijack. Both sessions work as authentic session.
session_regenerate_id() must result in only one active session
eventually.

Although session module has over 10 years of history, session module
lacks basic feature and is not implemented fully yet. As I mentioned
in above manual pages, it does not have mandatory timestamp based
session management.

I proposed implementation [1], but it was declined even if it is
mandatory for session module to manage session data correctly and
precisely.

Obviously, other people disagree about how mandatory it is. :)

So you do not think timestamp based session management is not
mandatory. Then how do you accomplish securing session data?

• How to prevent race conditions by network and client?
  • How to recover from lost sessions? (Network race condition cannot be fixed)
  • How to prevent race conditions in browsers? (We cannot fix browsers)
• How to detect possible attacks?

If there is nothing we can do, we may leave problem as it is. However,
timestamp can resolve almost all issues. (My proposal attempt
reconnect session only once, so it could lose session but will be rare
compare to do nothing)

Some may think "timestamp management should be part of user task", but
even simple basic feature like session_regenerate_id() can NOT work as
it supposed without timestamp based management. (Other mandatory tasks
have problems also, but I ignore them for now)

I was under impression it already works as it supposed to, but obviously

Sudden loss of session is not something user expect as a normal behavior.

you are of different opinion, so I'd like to hear details about why. If
you're talking about the case where network connection drops in the
middle of reading the new session ID, I still think it is a very exotic
and rare use case and claiming this function needs to be deleted because
it doesn't cover this case makes little sense to me.

We have several bug reports for this. I personally experienced this
issue with very large web service also. It's not that rare. I observed
handful races per day for the application. I don't consider it rare
and ignorable.

I've been using PHP servers with session_regenerate_id() for many years
and never heard complaints about this. Of course, your user base may be
different, but I still question that we need to implement a complex
system and overhaul most of the session management to serve this rare case.

This is hard to notice, but it happens for sure. For example, session
ID being empty (this is client side race) had 17 votes.

https://bugs.php.net/bug.php?id=68063

I fixed this by rejecting and resetting empty session ID.
We have sudden session loss bug reports also. Following bug report has 8 votes.

https://bugs.php.net/bug.php?id=70584

This one cannot be fixed without timestamping. (Otherwise, use very
loose and insecure session management is required)

Session module should do better job and it can.

There is userland workaround as described. User can implement their
own session_regenerate_id() as described in the manual page.

Since session management is very important feature for web apps, we
shouldn't keep providing halfway implemented API forever.
Implementation or removal is required.
timestamp based (precise) session management again.

What substantial changes do you propose to make since the previous RFC?
We can't just keep voting on the same thing until we get result that you
like, that's not how it works.

I'm proposing 2 choices now.

• Adopting timestamp in session
• Remove features that cannot work correctly without timestamp.

session_regenerate_id() deprecation now and removal in future version.

This makes no sense to me, at least without a lot of additional
explanation.

Current session_regenerate_id() cannot do the optimal job for the
task. i.e. It results in empty session ID (my fix is merely a
workaround. The problem is still there), lost session ID, session
hijack attack is undetectable/cannot prevent. These issues are fatal.
IMHO. Therefore, timestamp is mandatory.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net