Securing Session INI Settings

By securing session related INI settings, you can improve session security. Some of important INI settings do not have recommended settings. You are responsible to hardening session settings.

• session.cookie_lifetime=0

  0 have special meaning. It tells browsers not to store cookie to permanent storage. Therefore, when browser is terminated, session ID cookie is deleted immediately. If developer set other than 0, it may allow other users to use the session ID. Most applications should use "0" for this.

  If auto login feature is required, implement your own secure auto login feature. Do not use long life session ID for it.

• session.use_cookies=On

  session.use_only_cookies=On

  Although HTTP cookie has some problems, cookie is preferred way to manage session ID. Use only cookies for session ID management when it is possible. Most applications should use cookie for session ID.

  If session.use_only_cookies=Off, session module will use session ID values set by GET/POST/URL is used when session ID cookie is not initialized already.

• session.use_strict_mode=On

  Although, enabling session.use_strict_mode is mandatory. It is not enabled by default.

  This prevents session module to use uninitialized session ID. In other word, session module only accepts valid session ID generated by session module. It rejects session ID supplied by users.

  Because of cookie spec, attackers are able to set undeletable session ID cookies via locally setting cookie database or JavaScript injections. session.use_strict_mode can prevent attacker initialized session ID being used.

  Note:

  Attackers may initialize session ID by their device and may set the session ID to victim. They must keep the session ID active to abuse. Attackers require additional steps to perform attack with this attack scenario. Therefore, session.use_strict_mode works as the mitigation.

• session.cookie_httponly=On

  Disallow access to session cookie by JavaScript. This setting prevents cookies stolen by JavaScript injection.

  It is possible to use session ID as CSRF protection key, but this is not recommended. For example, HTML source may be saved and sent to other users. Developer should not write session ID in web pages for better security. Almost all applications must use httponly attribute for session ID cookie.

  Note:

  CSRF protection token should be renewed periodically just like session ID

• session.cookie_secure=On

  Allows access to session ID cookie only when protocol is HTTPS. If your web site is HTTPS only web site, you must enable this setting.

  HSTS should be considered for HTTPS only web site.

• session.gc_maxlifetime=[choose smallest possible]

  session.gc_maxlifetime is setting for deleting obsolete session ID. Reliance on this setting is NOT recommend. You should manage session life time by time-stamp by yourself.

  Session GC(garbage collection) is better to be performed by session_gc(). session_gc() function is better to be executed by task managers. e.g. cron on UNIX like systems.

  GC is performed by probability by default. This setting does not guarantee old session deletion. Although developer cannot rely on this setting, setting this to smallest possible value is recommended. Adjust session.gc_probability and session.gc_divisor so that obsolete sessions are deleted by appropriate frequency. If auto login feature is required, implement your own secure auto login feature. Never use long life session ID for it.

  Note:

  Some session save handler modules do not use this setting for probability based expiration . e.g. memcached, memcache. Refer to session save handler documentation for details.

• session.use_trans_sid=Off

  Use of transparent session ID management is not prohibited. You may use it when it is needed. However, disabling transparent session ID management would improve general session ID security by removing possibility of session ID injection and session ID leak.

  Note:

  Session ID may leak from bookmarked URL, e-mailed URL, saved HTML source.

• session.trans_sid_tags=Off

  (PHP 7.1.0 >=) You should not rewrite unneeded HTML tags. Default would be good enough for most usage. Older PHP uses url_rewriter.tags for this.

• session.trans_sid_hosts=Off

  (PHP 7.1.0 >=) This INI defines whitelist hosts that allows trans sid rewrite. Never add untrusted host. Session module allow only $_SERVER['HTTP_HOST'] when this setting is empty.

• session.referer_check=[your originating URL]

  When session.use_trans_sid is enabled, use of this setting is recommended. It reduces risk of session ID injection. If your site is http://example.com/, set http://example.com/ to it. Note that when HTTPS is used, browser will not send referrer header. Browser may not send referrer header by configuration. Therefore, this setting is not reliable security measure.

• session.cache_limiter=nocache

  Make sure HTTP contents are not cached for authenticated session. Allow caching only when contents is not private. Otherwise, contents may be exposed. "private" may be used if HTTP content does not include security sensitive data. Note that "private" may leave private data cached by shared clients. "public" may be used only when HTTP content does not contain any private data at all.

• session.sid_length="48"

  (PHP 7.1.0 >=) Longer session ID results in stronger session ID. Developer should consider session ID length 32 chars or more. At least 26 chars is required when session.sid_bits_per_character="5".

• session.sid_bits_per_character="6"

  (PHP 7.1.0 >=) The more bits in a session ID char, session module generates stronger session ID for the same session ID length.

• session.hash_function="sha256"

  (PHP 7.1.0 <) Stronger hash function will generates stronger session ID. Although hash collision is unlikely even with MD5 hash, developers should use SHA-2 or stronger hash functions for the task. Developers may use stronger hashes like sha384 and sha512. Make sure you feed long enough entropy for the hash function used.