By securing session related INI settings, developers can improve session security. Some important INI settings do not have any recommended settings. Developers are responsible for hardening session settings.
0 possesses a particular meaning. It informs browsers not to store the cookie to permanent storage. Therefore, when the browser is terminated, the session ID cookie is deleted immediately. If developers set this other than 0, it may allow other users to use the session ID. Most applications should use "0" for this.
If an auto-login feature is required, developers must implement their own secure auto-login feature. Do not use long life session IDs for this. More information can be found above in the relevant section.
Although HTTP cookies suffer some problems, cookies remain the preferred way to manage session IDs. Only use cookies for session ID management when it is possible. Most applications should use a cookie for the session ID.
If session.use_only_cookies=Off, the session module will use the session ID values set by GET/POST/URL provided the session ID cookie is uninitialized.
Although, enabling session.use_strict_mode is mandatory for secure sessions. It is disabled by default.
This prevents the session module to use an uninitialized session ID. Put differently, the session module only accepts valid session IDs generated by the session module. It rejects any session ID supplied by users.
Due to the cookie specification, attackers are capable to place non removable session ID cookies by locally setting a cookie database or JavaScript injections. session.use_strict_mode can prevent an attacker initialized session ID of being used.
Note:
Attackers may initialize a session ID with their device and may set the session ID of the victim. They must keep the session ID active to abuse. Attackers require additional steps to perform an attack in this scenario. Therefore, session.use_strict_mode works as a mitigation.
Refuses access to the session cookie from JavaScript. This setting prevents cookies snatched by a JavaScript injection.
It is possible to use a session ID as a CSRF token, but this is not recommended. For example, HTML sources may be saved and sent to other users. Developers should not write session IDs in web pages for better security. Almost all applications must use the httponly attribute for the session ID cookie.
Note:
The CSRF token should be renewed periodically just like the session ID.
Allow access to the session ID cookie only when the protocol is HTTPS. If a website is only accessible via HTTPS, it should enable this setting.
HSTS should be considered for websites accessible only via HTTPS.
session.cookie_samesite="Lax" or session.cookie_samesite="Strict"
As of PHP 7.3 the "SameSite" attribute can be set for the session ID cookie. This attribute is a way to mitigate CSRF (Cross Site Request Forgery) attacks.
The difference between Lax and Strict is the accessibility of the cookie in requests originating from another registrable domain employing the HTTP GET method. Cookies using Lax will be accessible in a GET request originated from another registrable domain, whereas cookies using Strict will not.
session.gc_maxlifetime=[choose smallest possible]
session.gc_maxlifetime is a setting for deleting obsolete session ID. Reliance on this setting is not recommended. Developers should manage the lifetime of sessions with a timestamp by themselves.
Session GC (garbage collection) is best performed by using session_gc(). The session_gc() function should be executed by a task managers. E.g. cron on UNIX like systems.
GC is performed by probability by default. This setting does not guarantee that an outdated session is deleted. Although developers cannot rely on this setting, specifying it to the smallest possible value is recommended. Adjusting session.gc_probability and session.gc_divisor so that obsolete sessions are deleted at an appropriate frequency. If an auto-login feature is required, developers must implement their own secure auto-login feature, see above for more information. Never use long life session ID for this feature.
Note:
Some session save handler modules do not use this setting for probability based expiration. E.g. memcached, memcache. Refer to the session save handler documentation for details.
Use of a transparent session ID management is not prohibited. Developers may employ it when it is required. However, disabling transparent session ID management improves the general session ID security by eliminating the possibility of a session ID injection and/or leak.
Note:
Session ID may leak from bookmarked URLs, e-mailed URLs, saved HTML source, etc.
session.trans_sid_tags=[limited tags]
(PHP 7.1.0 >=) Developers should not rewrite unneeded HTML tags. Default value should be sufficient for most usages. Older PHP versions use url_rewriter.tags instead.
session.trans_sid_hosts=[limited hosts]
(PHP 7.1.0 >=) This INI defines whitelist hosts that allows trans sid rewrite. Never add untrusted hosts. Session module only allows $_SERVER['HTTP_HOST'] when this setting is empty.
session.referer_check=[originating URL]
When session.use_trans_sid is enabled. It reduces the risk of session ID injection. If a website is http://example.com/, set http://example.com/ to it. Note that with HTTPS browsers will not send the referrer header. Browsers may not send the referrer header by configuration. Therefore, this setting is not a reliable security measure. Use of this setting is recommended.
session.cache_limiter=nocache
Ensure HTTP content are uncached for authenticated sessions. Allow caching only when the content is not private. Otherwise, content may be exposed. "private" may be employed if HTTP content does not include security sensitive data. Note that "private" may transmit private data cached by shared clients. "public" must only be used when HTTP content does not contain any private data at all.
session.sid_length="48"
(PHP 7.1.0 >=) Longer session IDs results in stronger session IDs. Developers should consider a session ID length of 32 characters or more. At least 26 characters are required when session.sid_bits_per_character="5".
session.sid_bits_per_character="6"
(PHP 7.1.0 >=) The more bits there are in a session ID character, the stronger the session ID generated by the session module is for an identical session ID length.
session.hash_function="sha256"
(PHP 7.1.0 <) A stronger hash function will generate a stronger session ID. Although hash collision is unlikely even with the MD5 hashing algorithm, developers should use SHA-2 or a stronger hashing algorithm like sha384 and sha512. Developers must ensure they feed a long enough entropy for the hashing function used.