High-secured session principles for a safe login session

0 投票
最新提问 用户: (140 分)

I'm starting to concern about the login-process security related to the sessions.

I've read many articles on the Web but most of them are old and don't take in consideration nowadays tools, although the principles are basically always the same. I want to share with you what I understood so that you can slap my face if I'm saying something wrong, as parents with children, asking you also for some explanation.

1) php.ini set up

This is how I think I should configure the php.ini to have a proper session security. If something is missing, please tell me.

  1. session.use_cookies = 1
  2. session.use_only_cookies = 1 Based on what I understood about sessions working principles, the unique ID assigned to the user when it connects to the website can be stored in the URL (appending it, I suppose), in a cookie or both. This option set to on would say to the server "Hey, I want that you store the session ID only in the cookie".
  3. session.cookie_secure = 1 If set to on, the session ID is stored into a cookie only if an HTTPS connection is detected. I didn't really get the utility of this option: if I buy an SSL (TLS) certificate my client will communicate to the server only under an HTTPS connection, right? And if the HTTPS connection fails it wouldn't switch to an HTTP one I guess, right? I think it would display a CONNECTION_ERROR. If yes, also the session cookies will always be sent over HTTPS so how setting this option to On would increase the security?
  4. session.cookie_httponly = 1 It's quite clear it's an important feature to avoid XSS attacks, since the session cookie can be retrieved only by an HTTP connection and not by anyone using any scripting language as JavaScript.
  5. session.use_strict_mode = 1 From PHP Manual:

    it specifies whether the module will use strict session id mode. If this mode is enabled, the module does not accept uninitialized session ID. If uninitialized session ID is sent from browser, new session ID is sent to browser. Applications are protected from session fixation via session adoption with strict mode. Defaults to 0 (disabled). Note: Enabling session.use_strict_mode is mandatory for general session security. All sites are advised to enable this.

    It seems to be an important option; but why it's set on 0 by default, then? And what it concretely achieves? 'Cause I didn't understand its purpose. Can someome make me a concrete example?

2) Session hijacking

To complicate the attacker life, these are the tools I think should be used. If anyone knows some more, please tell me.

  1. php.ini - A proper php.ini configuration is the base.
  2. HTTPS connection - This should avoid the session sniffing since the data exchanged by client and server is crypted.
  3. Session ID regeneration - Regenerating the session ID in two cases:

    a) when the user log-in into a higher security level area;

    b) every X time, eg 20 minutes, avoiding the so called session fixation

    Regarding this part, I want to ask you the difference between session_regenerate_id() and session_create_id() 'cause I didn't get it. Has session_create_id() been created just to solve the session_regenerate_id() instability reported in the PHP Manual? What's the aim to put a prefix to the session ID? Is it like a personal salt? When and why I should use one or the other?

  4. Session timeout - After X time of inactivity, destroy the login session so that the user must log-in again.

Concluding, these are the things I understood must be implemented to have a secure session, in particular a login session. With these implementations, is the system strong enough? Or should I add something more to make it stronger?


0 投票
最新回答 用户: (660 分)
  1. 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.

  1. 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_probability and gc_divisor), so this is no guarantee that the files will be wiped immediately or even close to their expiry.

欢迎来到 Security Q&A ,有什么不懂的可以尽管在这里提问,你将会收到社区其他成员的回答。