yii 2.0.47会话劫持漏洞风险源于存储不安全、传输未加密、id易窃取或预测；需从存储（改用redis/dbsession并加keyprefix）、传输（cookie设httponly/secure/samesite）、生成（登录后regenerateid(true)）、销毁（设timeout、限制并发、避免存敏感数据）四环节加固。
Yii 2.0.47 会话劫持漏洞的核心风险在于会话数据存储不安全、传输过程未保护、以及会话标识（session ID）易被窃取或预测。加固不是加一层“防护罩”，而是从存储、传输、生成、销毁四个环节切断攻击路径。
强制改用 Redis 或数据库存储会话
默认的 FileSession 在多机环境完全不可用，且文件权限不当会导致 session 文件被直接读取。必须替换：
- 启用 redis 扩展，配置
'class' => 'yii\redis\Session'，并确保redis组件已正确定义（含hostname、port、database和可选password） - 若用数据库，必须使用
yii\web\DbSession，建表语句中id字段须为VARCHAR(128)并设为主键+索引，否则高并发下锁表严重 - 所有 session key 必须加
keyPrefix（如'yii2_session:'），避免与其他应用冲突
会话 Cookie 必须设安全属性
仅靠服务端存储升级不够，Cookie 本身要防窃听和劫持：
-
'useCookies' => true（不能关） 'cookieParams' => [ 'httpOnly' => true, 'secure' => true, 'sameSite' => 'Strict' ]-
'secure'要求全站走 HTTPS；若暂未部署，至少在 Nginx/Apache 中强制重定向，不能依赖 PHP 层判断
禁用会话固定，强制登录后再生 ID
攻击者诱使用户用旧 session ID 登录后即可复用——Yii 默认不自动处理这点：
- 在登录成功后手动调用
Yii::$app->session->regenerateID(true) - 确保
regenerateID()的$deleteOldSession参数为true，防止旧 ID 继续有效 - 不要依赖框架自动刷新；检查 LoginForm 或自定义 AuthController 的 login() 方法末尾是否已加入该调用
限制会话生命周期与并发数
延长有效期等于扩大攻击窗口，放任多设备共用等于增加泄露面：
- 设置
'timeout' => 1800（30 分钟无操作过期），敏感操作（如支付页）可进一步缩短 - 在用户模型中记录当前活跃 session ID 列表，登录时比对：若已有其他设备在线，可选择踢出旧会话或要求二次验证
- 避免将敏感字段（如用户角色、权限列表）长期存入 session；改用实时查库或短时效缓存
