- session.use_strict_mode = 1 From PHP Manual: [...]
It seems to be an important option; but why it's set on 0 by default, then?
Dunno why it is not enabled by default; probably to prevent possible issues/side effects this could have with existing scripts.
As for what it does:
Without strict mode, if I send a non-existing session id
abc123 to your app, it would create a new session using that id. This is potentially dangerous in combination with other possible security holes, and part of session fixation.
If for example via an XSS vulnerability I was able to send a link to a user that has admin rights on your page that would set a session cookie using my given id in their browser, and they then login as admin - then I would know their session id (because I specified it), so I could create the session cookie using the same ID in my browser then, and I would be logged in to your site as this admin user.
Strict mode prevents that. The admin user comes to your site with my faked session id
abc123. System realizes that a session with that id does not exist - and creates a new session with a new id, instead of creating a new session using the id
abc123. So the site admin now has a session with an id that I dont know, meaning I can not proceed with my attack by simply faking the session cookie.
Regarding this part, I want to ask you the difference between session_regenerate_id() and session_create_id()
session_regenerate_id creates a new id for the existing session. It creates a new session file (when using the default storage mechanism), and optionally deletes the existing one that was named using the old session id. And it updates the session cookie with that new id.
session_create_id only creates a new session id, nothing else. It does not update the session cookie, nor does it update the session storage. That would be the apps own responsibility in this case.
- Session timeout - After X time of inactivity, destroy the login session so that the user must log-in again.
Be aware that PHPs config setting
session.gc_maxlifetime is actually named wrong - actually, it specifies a minimal lifetime. Session files that are older than this minimal lifetime can be cleaned up by the garbage collector; but the GC is triggered randomly (depending on
gc_divisor), so this is no guarantee that the files will be wiped immediately or even close to their expiry.