PHP session.use_strict_mode 怎样拒绝未知会话 ID

我在排查登录态异常时，最容易误判的一点是：浏览器带来的 session ID 不等于服务端已经存在的会话。PHP 的 session.use_strict_mode 开启后，会先判断这个 ID 是否已经由会话存储初始化；如果是未知 ID，PHP 不会直接采用它，而是给浏览器发送一个新的会话 ID。

官方地址：https://www.php.net/manual/en/session.configuration.php

实际配置时，把 session.use_strict_mode 设为 1 或 On，并确保它在 session_start() 之前生效。默认配置是关闭的；如果使用自定义 session handler，还必须确认它实现了 ID 校验回调。

• 已有 ID：存储端能找到对应会话时，PHP 才会继续使用它。
• 未知 ID：strict mode 不会把它当成新会话直接接纳，而是发送新的 ID。
• 自定义 handler：没有 validateId() 或 validate_sid 时，开关可能形同虚设。

先区分未知会话 ID 与已有会话

session ID 更像一个索引，不是会话内容本身。浏览器提交一个值后，PHP 还要交给当前的 session save handler 查询。如果查询到已经初始化的会话，应用可以继续读取 $_SESSION；如果查询不到，这个 ID 就属于未初始化或未知 ID。

这项区别对会话固定风险很重要。应用如果无条件接受外部带来的未知 ID，就可能让攻击者先选定一个 ID，再诱导用户使用同一个 ID。strict mode 的作用是让“未被服务端初始化的 ID”不能直接成为应用会话。它是缓解措施，不代替登录成功后的会话轮换、HTTPS 和安全 Cookie 配置。

在会话启动前开启 strict mode

生产环境优先在 php.ini 或对应的 PHP-FPM 池配置中设置，避免只有某一个入口脚本临时生效。若要在代码中设置，必须放在 session_start() 之前；会话已经启动后再修改，通常不能改变本次会话的初始化决策。

如果你能修改服务器配置，也可以使用下面的设置：

; 只接受已经由会话存储初始化的 ID
session.use_strict_mode = 1

; 只通过 Cookie 传递 session ID，避免把 ID 放进 URL
session.use_cookies = 1
session.use_only_cookies = 1

这里的 session.use_only_cookies 是会话 ID 传递方式的补充设置，不是 strict mode 的替代品。两者解决的问题不同：前者限制 ID 的传递位置，后者判断这个 ID 是否已经被会话模块初始化。

理解未知 ID 的处理结果

开启 strict mode 后，浏览器即使带来了一个格式看起来正常、但存储端不存在的 ID，PHP 也不会把它当成合法旧会话。官方手册描述的结果是：模块不接受未初始化的 session ID，并向浏览器发送新的 session ID。应用层应把这理解为“本次请求得到一个新会话”，而不是把旧 ID 修复成有效登录态。

这段代码没有读取或拼接请求里的 session ID。会话模块负责解析 Cookie 和查找存储，业务代码只使用经过 PHP 会话机制加载后的 $_SESSION。登录成功后仍应按应用需要调用 session_regenerate_id(true)，避免把登录前后的会话状态长期绑定在同一个 ID 上。

检查自定义 session handler 的校验能力

这是我觉得最值得单独检查的兼容点：官方文档明确提醒，如果自定义 session handler 没有实现 SessionUpdateTimestampHandlerInterface::validateId()，也没有提供 validate_sid 回调，那么 strict mode 实际上会被禁用。配置文件里看到 On，不代表自定义存储已经能判断 ID 是否存在。

因此迁移到 Redis、数据库或其他自定义存储时，要把 ID 校验能力列入接口契约。不要只检查“能否读写 session”，还要确认 handler 是否能回答“这个 ID 是否已经初始化”。如果使用 PHP 内置的 SessionHandler，也要注意官方文档指出它本身不实现 validateId()。

常见问题

strict mode 会不会让所有新用户都无法创建会话？

不会。它拒绝的是浏览器提交的未知 ID；当 PHP 需要创建新会话时，会生成新的 session ID。不要把“拒绝外部未知 ID”和“禁止创建新会话”混为一谈。

只设置 session.use_strict_mode 就够了吗？

不够。它主要处理未知 ID 的接纳问题。生产会话还应结合 Cookie 传递、HTTPS、HttpOnly、SameSite、登录后的 ID 轮换和服务端会话生命周期管理。

自定义 handler 为什么让 strict mode 看起来失效？

常见原因是 handler 没有实现官方要求的 ID 校验能力。读写 session 数据的接口与判断 ID 是否已初始化是两件事，应分别检查。

我的实践结论是：先把 session.use_strict_mode 在会话启动前打开，再把自定义 handler 的 ID 校验当成正式接口来维护。这样浏览器提供的只是候选 ID，真正能被应用采用的仍由服务端会话存储决定。