保护 Session INI 设置

通过保护与 Session 相关的 INI 设置，开发人员可以提高 Session 的安全性。一些重要的 INI 设置没有任何推荐的设置。开发人员负责加强 Session 设置。

• session.cookie_lifetime=0

  0 具有特殊的含义。它通知浏览器不要将 Cookie 存储到永久存储中。因此，当浏览器终止时，Session ID Cookie 会立即被删除。如果开发人员将其设置为非 0 值，则可能允许其他用户使用 Session ID。大多数应用程序都应该为此使用 "0"。

  如果需要自动登录功能，开发人员必须实现自己的安全自动登录功能。不要为此使用长生命周期的 Session ID。更多信息可以在上面相关部分找到。

• session.use_cookies=On

  session.use_only_cookies=On

  尽管 HTTP Cookie 存在一些问题，但 Cookie 仍然是管理 Session ID 的首选方式。仅在可能的情况下使用 Cookie 来管理 Session ID。大多数应用程序都应该使用 Cookie 来存储 Session ID。

  如果 session.use_only_cookies=Off，则 Session 模块将使用通过 GET 或 POST 设置的 Session ID 值，前提是 Session ID Cookie 未初始化。

• session.use_strict_mode=On

  尽管启用 session.use_strict_mode 对安全 Session 来说是强制性的，但它默认情况下是禁用的。

  这可以防止 Session 模块使用未初始化的 Session ID。换句话说，Session 模块仅接受 Session 模块生成的有效 Session ID。它拒绝用户提供的任何 Session ID。

  由于 Cookie 规范，攻击者能够通过本地设置 Cookie 数据库或 JavaScript 注入来放置不可移除的 Session ID Cookie。session.use_strict_mode 可以防止使用攻击者初始化的 Session ID。

  注意:

  攻击者可能会使用其设备初始化 Session ID，并可能设置受害者的 Session ID。他们必须保持 Session ID 活动才能滥用。在这种情况下，攻击者需要执行其他步骤才能执行攻击。因此，session.use_strict_mode 作为一种缓解措施。

• session.cookie_httponly=On

  拒绝 JavaScript 访问 Session Cookie。此设置可防止 Cookie 被 JavaScript 注入窃取。

  可以使用 Session ID 作为 CSRF 令牌，但不推荐这样做。例如，HTML 源代码可能会被保存并发送给其他用户。开发人员不应在网页中写入 Session ID 以提高安全性。几乎所有应用程序都必须为 Session ID Cookie 使用 httponly 属性。

  注意:

  CSRF 令牌应该像 Session ID 一样定期更新。

• session.cookie_secure=On

  仅当协议为 HTTPS 时才允许访问 Session ID Cookie。如果网站只能通过 HTTPS 访问，则应启用此设置。

  对于只能通过 HTTPS 访问的网站，应考虑使用 HSTS。

• session.cookie_samesite="Lax" 或 session.cookie_samesite="Strict"

  从 PHP 7.3 开始，可以为 Session ID Cookie 设置 "SameSite" 属性。此属性是缓解 CSRF（跨站点请求伪造）攻击的一种方法。

  Lax 和 Strict 之间的区别在于 Cookie 在来自使用 HTTP GET 方法的其他可注册域的请求中的可访问性。使用 Lax 的 Cookie 将在来自其他可注册域的 GET 请求中可访问，而使用 Strict 的 Cookie 则不会。

• session.gc_maxlifetime=[选择尽可能小的值]

  session.gc_maxlifetime 是用于删除过时 Session ID 的设置。不推荐依赖此设置。开发人员应该自己使用时间戳管理 Session 的生命周期。

  Session GC（垃圾回收）最好通过使用 session_gc() 来执行。session_gc() 函数应由任务管理器执行。例如，在类 Unix 系统上的 cron。

  GC 默认情况下以概率方式执行。此设置不保证删除过时的 Session。尽管开发人员不能依赖此设置，但建议将其指定为尽可能小的值。调整 session.gc_probability 和 session.gc_divisor，以便以适当的频率删除过时的 Session。如果需要自动登录功能，开发人员必须实现自己的安全自动登录功能，请参阅以上内容以获取更多信息。切勿为此功能使用长生命周期的 Session ID。

  注意:

  某些 Session 保存处理程序模块不使用此设置进行基于概率的过期。例如，memcached、memcache。有关详细信息，请参阅 Session 保存处理程序文档。

• session.use_trans_sid=Off

  不禁止使用透明 Session ID 管理。开发人员可以在需要时使用它。但是，禁用透明 Session ID 管理可以通过消除 Session ID 注入和/或泄漏的可能性来提高 Session ID 的整体安全性。

  注意:

  Session ID 可能会从书签 URL、电子邮件 URL、保存的 HTML 源代码等泄漏。

• session.trans_sid_tags=[受限标签]

  (PHP 7.1.0 >=) 开发人员不应重写不需要的 HTML 标签。默认值应该足以满足大多数用途。旧版本的 PHP 使用 url_rewriter.tags 代替。

• session.trans_sid_hosts=[受限主机]

  (PHP 7.1.0 >=) 此 INI 定义允许 trans sid 重写的白名单主机。切勿添加不受信任的主机。当此设置为空时，Session 模块仅允许 $_SERVER['HTTP_HOST']。

• session.referer_check=[源 URL]

  当启用 session.use_trans_sid 时。它降低了 Session ID 注入的风险。如果网站为 http://example.com/，则将其设置为 http://example.com/。请注意，使用 HTTPS 的浏览器不会发送 Referer 标头。浏览器可以通过配置不发送 Referer 标头。因此，此设置不是可靠的安全措施。建议使用此设置。

• session.cache_limiter=nocache

  确保已认证的 Session 的 HTTP 内容未被缓存。仅在内容不私密时才允许缓存。否则，内容可能会泄露。"private" 可用于 HTTP 内容不包含安全敏感数据的情况。请注意，"private" 可能会传输由共享客户端缓存的私有数据。"public" 只能在 HTTP 内容根本不包含任何私有数据时使用。

• session.hash_function="sha256"

  (PHP 7.1.0 <) 更强大的哈希函数将生成更强大的 Session ID。尽管即使使用 MD5 哈希算法，哈希冲突也不太可能发生，但开发人员仍应使用 SHA-2 或更强大的哈希算法，如 sha384 和 sha512。开发人员必须确保他们为使用的哈希函数提供足够长的 熵。

• session.save_path=[非世界可读目录]

  如果将其设置为世界可读目录，例如 /tmp（默认值），则服务器上的其他用户可以通过获取该目录中文件的列表来劫持 Session。