<?php
include_once $_SERVER['DOCUMENT_ROOT'] . '/include/shared-manual.inc';
$TOC = array();
$TOC_DEPRECATED = array();
$PARENTS = array();
include_once dirname(__FILE__) ."/toc/session.security.inc";
$setup = array (
  'home' => 
  array (
    0 => 'index.php',
    1 => 'PHP Manual',
  ),
  'head' => 
  array (
    0 => 'UTF-8',
    1 => 'uk',
  ),
  'this' => 
  array (
    0 => 'session.security.ini.php',
    1 => 'Securing Session INI Settings',
    2 => 'Securing Session INI Settings',
  ),
  'up' => 
  array (
    0 => 'session.security.php',
    1 => 'Sessions and Security',
  ),
  'prev' => 
  array (
    0 => 'features.session.security.management.php',
    1 => 'Session Management Basics',
  ),
  'next' => 
  array (
    0 => 'ref.session.php',
    1 => 'Session Функції',
  ),
  'alternatives' => 
  array (
  ),
  'source' => 
  array (
    'lang' => 'en',
    'path' => 'reference/session/security.xml',
  ),
  'history' => 
  array (
  ),
);
$setup["toc"] = $TOC;
$setup["toc_deprecated"] = $TOC_DEPRECATED;
$setup["parents"] = $PARENTS;
manual_setup($setup);

contributors($setup);

?>
<div id="session.security.ini" class="sect1">
  <h2 class="title">Securing Session INI Settings</h2>

  <p class="para">
   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.
  </p>

  <ul class="itemizedlist">
    <li class="listitem">
     <p class="para">
      <a href="session.configuration.php#ini.session.cookie-lifetime" class="link">session.cookie_lifetime</a>=0
     </p>
     <p class="para">
      <code class="literal">0</code> 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 &quot;<code class="literal">0</code>&quot; for this.
     </p>
     <p class="para">
      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.
     </p>
    </li>

    <li class="listitem">
     <p class="para">
      <a href="session.configuration.php#ini.session.use-cookies" class="link">session.use_cookies</a>=On
     </p>
     <p class="para">
      <a href="session.configuration.php#ini.session.use-only-cookies" class="link">session.use_only_cookies</a>=On
     </p>
     <p class="para">
      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.
     </p>
     <p class="para">
      If <a href="session.configuration.php#ini.session.use-only-cookies" class="link">session.use_only_cookies</a>=Off,
      the session module will use the session ID values set by
      GET or POST provided the session ID cookie is uninitialized.
     </p>
    </li>

    <li class="listitem">
     <p class="para">
      <a href="session.configuration.php#ini.session.use-strict-mode" class="link">session.use_strict_mode</a>=On
     </p>
     <p class="para">
      Although, enabling
      <a href="session.configuration.php#ini.session.use-strict-mode" class="link">session.use_strict_mode</a>
      is mandatory for secure sessions. It is disabled by default.
     </p>
     <p class="para">
      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.
     </p>
     <p class="para">
      Due to the cookie specification, attackers are capable to place
      non-removable session ID cookies by locally setting a cookie database
      or JavaScript injections.
      <a href="session.configuration.php#ini.session.use-strict-mode" class="link">session.use_strict_mode</a>
      can prevent an attacker-initialized session ID of being used.
     </p>
     <blockquote class="note"><p><strong class="note">Зауваження</strong>: 
      <p class="para">
       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,
       <a href="session.configuration.php#ini.session.use-strict-mode" class="link">session.use_strict_mode</a>
       works as a mitigation.
      </p>
     </p></blockquote>
    </li>

    <li class="listitem">
     <p class="para">
      <a href="session.configuration.php#ini.session.cookie-httponly" class="link">session.cookie_httponly</a>=On
     </p>
     <p class="para">
      Refuses access to the session cookie from JavaScript.
      This setting prevents cookies snatched by a JavaScript injection.
     </p>
     <p class="para">
      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.
     </p>
     <blockquote class="note"><p><strong class="note">Зауваження</strong>: 
      <p class="para">
       The CSRF token should be renewed periodically just like the session ID.
      </p>
     </p></blockquote>
    </li>

    <li class="listitem">
     <p class="para">
      <a href="session.configuration.php#ini.session.cookie-secure" class="link">session.cookie_secure</a>=On
     </p>
     <p class="para">
      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.
     </p>
     <p class="para">
      HSTS should be considered for websites accessible only via HTTPS.
     </p>
    </li>

    <li class="listitem">
     <p class="para">
      <a href="session.configuration.php#ini.session.cookie-samesite" class="link">session.cookie_samesite</a>=&quot;Lax&quot; or
      <a href="session.configuration.php#ini.session.cookie-samesite" class="link">session.cookie_samesite</a>=&quot;Strict&quot;
     </p>
     <p class="para">
      As of PHP 7.3 the <code class="literal">&quot;SameSite&quot;</code> attribute can be set for the session ID cookie.
      This attribute is a way to mitigate CSRF (Cross Site Request Forgery) attacks.
     </p>
     <p class="para">
      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.
     </p>
    </li>

    <li class="listitem">
     <p class="para">
      <a href="session.configuration.php#ini.session.gc-maxlifetime" class="link">session.gc_maxlifetime</a>=[choose smallest possible]
     </p>
     <p class="para">
      <a href="session.configuration.php#ini.session.gc-maxlifetime" class="link">session.gc_maxlifetime</a>
      is a setting for deleting obsolete session ID.
      Reliance on this setting is <em>not</em> recommended.
      Developers should manage the lifetime of sessions with a timestamp by themselves.
     </p>
     <p class="para">
      Session GC (garbage collection) is best performed by using <span class="function"><a href="function.session-gc.php" class="function">session_gc()</a></span>.
      The <span class="function"><a href="function.session-gc.php" class="function">session_gc()</a></span> function should be executed by a task
      managers. E.g. cron on UNIX like systems.
     </p>
     <p class="para">
      GC is performed by probability by default.
      This setting does <em>not</em> guarantee that an outdated
      session is deleted.
      Although developers cannot rely on this setting,
      specifying it to the smallest possible value is recommended.
      Adjusting <a href="session.configuration.php#ini.session.gc-probability" class="link">session.gc_probability</a>
      and <a href="session.configuration.php#ini.session.gc-divisor" class="link">session.gc_divisor</a> 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.
     </p>
     <blockquote class="note"><p><strong class="note">Зауваження</strong>: 
      <p class="para">
       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.
      </p>
     </p></blockquote>
    </li>

    <li class="listitem">
     <p class="para">
      <a href="session.configuration.php#ini.session.use-trans-sid" class="link">session.use_trans_sid</a>=Off
     </p>
     <p class="para">
      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.
     </p>
     <blockquote class="note"><p><strong class="note">Зауваження</strong>: 
      <p class="para">
       Session ID may leak from bookmarked URLs, e-mailed URLs, saved HTML source, etc.
      </p>
     </p></blockquote>
    </li>

    <li class="listitem">
     <p class="para">
      <a href="session.configuration.php#ini.session.trans-sid-tags" class="link">session.trans_sid_tags</a>=[limited tags]
     </p>
     <p class="para">
      (PHP 7.1.0 &gt;=) Developers should not rewrite unneeded HTML tags.
      Default value should be sufficient for most usages.
      Older PHP versions use
      <a href="outcontrol.configuration.php#ini.url-rewriter.tags" class="link">url_rewriter.tags</a> instead.
     </p>
    </li>

    <li class="listitem">
     <p class="para">
      <a href="session.configuration.php#ini.session.trans-sid-hosts" class="link">session.trans_sid_hosts</a>=[limited hosts]
     </p>
     <p class="para">
      (PHP 7.1.0 &gt;=) This INI defines whitelist hosts that allows trans sid rewrite.
      Never add untrusted hosts.
      Session module only allows <code class="literal">$_SERVER[&#039;HTTP_HOST&#039;]</code>
      when this setting is empty.
     </p>
    </li>

    <li class="listitem">
     <p class="para">
      <a href="session.configuration.php#ini.session.referer-check" class="link">session.referer_check</a>=[originating URL]
     </p>
     <p class="para">
      When <a href="session.configuration.php#ini.session.use-trans-sid" class="link">session.use_trans_sid</a>
      is enabled.
      It reduces the risk of session ID injection.
      If a website is <code class="literal">http://example.com/</code>,
      set <code class="literal">http://example.com/</code> 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.
     </p>
    </li>

    <li class="listitem">
     <p class="para">
      <a href="session.configuration.php#ini.session.cache-limiter" class="link">session.cache_limiter</a>=nocache
     </p>
     <p class="para">
      Ensure HTTP content are uncached for authenticated sessions.
      Allow caching only when the content is not private.
      Otherwise, content may be exposed.
      <code class="literal">&quot;private&quot;</code> may be employed if HTTP content does not
      include security sensitive data.
      Note that <code class="literal">&quot;private&quot;</code> may transmit private data
      cached by shared clients.
      <code class="literal">&quot;public&quot;</code> must only be used when HTTP content does
      not contain any private data at all.
     </p>
    </li>

    <li class="listitem">
     <p class="para">
      <a href="session.configuration.php#ini.session.hash-function" class="link">session.hash_function</a>=&quot;sha256&quot;
     </p>
     <p class="para">
      (PHP 7.1.0 &lt;) 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
      <a href="session.configuration.php#ini.session.entropy-length" class="link">entropy</a>
      for the hashing function used.
     </p>
    </li>

    <li class="listitem">
     <p class="para">
      <a href="session.configuration.php#ini.session.save-path" class="link">session.save_path</a>=[non world-readable directory]
     </p>
     <p class="para">
      If this is set to a world-readable directory, such as
      <var class="filename">/tmp</var> (the default), other users on the
      server may be able to hijack sessions by getting the list of
      files in that directory.
     </p>
    </li>

  </ul>
 </div><?php manual_footer($setup); ?>