PHP怎么处理用户会话固定攻击_PHP Session安全加固【详解】

登录成功的那一刻，如果没做 session_regenerate_id(true)，那基本等于把刚拿到的登录凭证明晃晃地递给了攻击者。这不是什么锦上添花的功能，而是防御会话固定攻击的唯一有效动作——必须在身份确认无误的瞬间，切断旧会话ID与用户身份的绑定。

登录验证通过后必须立刻执行 session_regenerate_id(true)

时机很关键：要把这段代码放在 $_SESSION 写入敏感数据（比如 user_id）之后、重定向之前。参数 true 不能省略——它强制删除旧会话文件，否则攻击者仍有可能读取到刚刚写入的登录态。同样需要注意，不能在 session_start() 后立即调用，也不能在密码错误时调用，那会暴露新ID给未授权用户。如果项目用了 Redis 这类自定义会话处理器，还得确认它是否支持 session_regenerate_id() 的清理逻辑。

登录页本身不能提前分配会话 ID

不少项目一打开 login.php 就执行 session_start()，这等于帮攻击者铺好了路。未登录态的页面，应尽量避免启动会话；如果确实需要存 CSRF Token 或登录失败计数，建议在登录前先执行 session_destroy() 和 session_unset()，再重新 session_start()。另外，必须禁用透明传输：ini_set('session.use_trans_sid', '0')，防止会话ID泄露在URL中。还要主动拦截手动传参的 PHPSESSID，比如 if (isset($_GET['PHPSESSID'])) { session_destroy(); exit; }。开发环境测试时拼 ?PHPSESSID=xxx 确实方便，但上线前必须关掉——这等于把钥匙挂在门把手上。

Cookie 属性和会话配置必须同步收紧

只换会话ID还不够，旧的Cookie如果还能被浏览器自动发送，攻击者就还能续命。session_set_cookie_params() 必须在 session_start() 前调用，参数包括 secure、httponly、samesite。同时启用严格模式：ini_set('session.use_strict_mode', '1')，拒绝未知ID的会话初始化。关键的 php.ini 配置还有：session.use_only_cookies = 1、session.cookie_httponly = 1、session.cookie_secure = 1。注意 session.cookie_samesite 在 PHP 7.3+ 才支持数组写法，低版本需要用字符串。

真正容易被忽略的是：攻击者往往从登录页开始布设陷阱，而开发者只盯着“登录成功后”这一段逻辑。会话固定攻击常和会话劫持组合利用，防御必须覆盖整个会话生命周期——从第一个请求开始，到每一次敏感操作前。