必须在认证成功后、写入敏感数据前调用session_regenerate_id(true)并清除旧Cookie，否则旧Session ID仍可被攻击者利用。
会话固定攻击（Session Fixation）的核心风险在于：用户登录前已被赋予一个可预测或可控的 Session ID，而登录后该 ID 未更换，导致攻击者能复用这个 ID 冒充已认证用户。
为什么必须 Regenerate Session ID？
登录动作本质是身份升级——从“未认证访客”变为“已认证用户”。若 Session ID 不变，攻击者早先诱导用户携带的 ID（比如通过恶意链接 ?PHPSESSID=abc123）就会直接继承认证状态。服务器无法区分这是用户自己生成的会话，还是被植入的会话。
所以关键不是“有没有 Session”，而是“登录前后 Session ID 是否强制刷新”。
Session Regenerate 的正确做法
仅调用 session_regenerate_id() 或 regenerate(true) 不够，必须配合以下条件：
- 必须在认证成功后、任何敏感数据写入 session 前执行——否则旧 ID 对应的 session 文件里可能已存入用户权限信息，再生只是多开一个空壳
-
参数
true（或delete_old_session = true）不可省略——它确保旧 session 数据被立即销毁，防止攻击者继续使用旧 ID 访问残留数据 - 需清除客户端残留的旧 Cookie——尤其当旧 ID 是通过 URL 参数或非 HttpOnly Cookie 注入时，要确保响应中 Set-Cookie 覆盖掉所有可能的旧值
常见错误场景
这些操作看似在“刷新”，实则无效：
- 登录前就调用 regenerate（如中间件里无条件刷新）——此时用户还没认证，刷新毫无意义
- 登录后只改 ID，但没删旧 session 文件（即没传
true）——旧 ID 仍可读取原 session 内容 - 用 GET/POST 参数传递 session ID 并允许其覆盖服务端生成值——这等于主动给攻击者留后门
- 未设置
Cookie: HttpOnly; Secure; SameSite=Lax——即使 ID 刷新了，也可能被 XSS 窃取或跨域滥用
框架中的典型实现
Laravel 示例（安全写法）：
if (Auth::attempt($credentials)) {
request()->session()->regenerate(true); // ✅ 强制销毁旧 session
return redirect()->intended('/dashboard');
}
PHP 原生示例：
session_start();
// ... 验证用户名密码
if ($valid) {
$_SESSION['user_id'] = $uid;
session_regenerate_id(true); // ✅ 删除旧文件并更新 Cookie
}
