PHP session.use_strict_mode 怎么防止会话固定：配置路径、旧 Cookie 与登录后轮换

登录接口如果直接沿用用户进入登录页时的会话 ID，攻击者就可能先准备一个 ID，再诱导用户在这个会话里完成登录。PHP 的稳妥做法是同时打开 session.use_strict_mode，拒绝浏览器带来的未初始化 ID，并在认证成功前调用 session_regenerate_id()，让登录态只落在新会话上。

session.use_strict_mode 负责不接纳陌生会话 ID，session_regenerate_id() 负责在登录等权限变化前换 ID；两步缺一不可。

先分清两类风险：陌生 ID 与旧 ID 复用

会话固定常被简化成“登录后换一个 Cookie”，但这里有两个不同判断。第一类是浏览器提交了服务器从未生成过的 session_id；第二类是用户登录前已有一个合法会话，登录接口却把认证状态继续写进这个旧 ID。

session.use_strict_mode 针对第一类问题：当浏览器提交未初始化 ID 时，PHP 会新建会话，而不是采用攻击者预先准备的 ID。它不能替代登录时的轮换，因为旧 ID 可能本来就是合法的匿名会话。

最小配置：让 PHP 拒绝未初始化 session_id

配置可以放在 php.ini、虚拟主机配置或应用启动阶段。若用应用代码设置，必须在第一次 session_start() 之前执行：

其中 session.use_only_cookies 会让会话 ID 只走 Cookie，不从 URL 或表单参数接收。生产环境还应检查 Cookie 的 secure、httponly 和 samesite 属性是否符合站点的 HTTPS 与跨站请求策略。图中只保留一条关键判断：陌生 session_id 进入严格模式后被拒绝，PHP 创建新会话。

登录成功前轮换，会话认证字段只写入新 ID

匿名用户打开登录页后，通常已经有一个会话，用来保存 CSRF 校验值或登录表单状态。验证账号密码成功后，先轮换 ID，再写认证信息：

这里的顺序是安全边界：session_regenerate_id 成功后，$_SESSION 才接收 user_id。如果轮换失败，应停止登录流程，不要把认证标志写回旧会话。图中的“登录成功”只通向 session_regenerate_id，随后才到 $_SESSION。

为什么不建议把旧会话立即删掉

PHP 手册特别提醒，并发请求或网络不稳定时，一条请求可能已经拿到新 ID，另一条请求仍在使用旧 ID。登录后立即销毁旧会话，会把正常请求误判成攻击并造成个人拒绝服务。

更稳妥的做法是给会话记录一个短暂的过渡时间戳。旧会话只允许完成有限的过渡处理，不再接受认证状态；等网络窗口过去，再由会话垃圾回收清理。不要把“换 ID”和“立刻删除全部旧数据”当成同一个动作。

自定义 SessionHandler 时要检查 validateId

如果应用通过 session_set_save_handler() 接入 Redis、数据库或其他存储，必须确认处理器实现了 SessionUpdateTimestampHandlerInterface::validateId()，或者提供等价的 validate_sid 回调。PHP 官方配置文档说明，缺少这项能力时，严格模式可能在实际运行中被削弱。

排查时可以先看运行时值，再看处理器实现：

输出只能证明配置值，不等于自定义处理器真的执行了 ID 校验。应补一条集成测试：带入从未创建的 Cookie，会话服务必须返回一个不同的新 ID；登录测试则应断言认证前后 session_id() 发生变化。

上线前的兼容检查

• 启动时机：ini_set 和 Cookie 参数必须发生在 session_start() 之前。
• 登录顺序：先检查凭据，再调用 session_regenerate_id(false)，最后写入 $_SESSION['user_id']。
• 并发处理：不要因一条旧 Cookie 请求立即清空全部会话，给移动网络保留短暂过渡窗口。
• 存储适配：自定义 SessionHandler 需验证陌生 ID，不要只看 session.use_strict_mode=1。

常见问题

打开 session.use_strict_mode 后还需要 session_regenerate_id 吗？

需要。严格模式防陌生 ID，轮换防合法匿名 ID 在登录后继续承载认证状态，两者解决的风险不同。

登录失败时是否也要轮换会话 ID？

通常先确保失败分支不写入认证字段；是否轮换要结合失败次数、CSRF 状态和并发体验设计，不能把轮换当成替代限流的措施。

session_regenerate_id(true) 是否更安全？

它会立即删除旧会话数据，但并发请求下可能造成正常用户状态丢失。默认应先评估会话存储、网络稳定性和旧会话过渡策略。

总结

PHP 会话固定防护是一条顺序明确的链路：session.use_strict_mode 拦住未初始化 session_id，登录成功后用 session_regenerate_id 换掉匿名 ID，再写入 $_SESSION 认证字段。若接入自定义存储，还要补上陌生 ID 校验和并发回归测试，配置值才不会停留在表面。