防范会话固定与Cookie劫持的核心在于前后端协同：登录成功后服务端必须销毁旧会话、生成新ID并重置Cookie，同时严格设置HttpOnly、Secure、SameSite三项安全属性，前端禁止手动操作或存储敏感令牌。
防范会话固定攻击和 Cookie 劫持，核心不在 JavaScript 本身做“拦截”或“加密”，而在于前后端协同配置——JS 只需不破坏安全机制，后端才是防线主体。关键动作是：登录成功时销毁旧会话、颁发新 Cookie，并严格设置安全属性。
登录时强制更新会话 ID（防会话固定）
会话固定攻击的前提是攻击者能诱导用户使用一个已知的会话 ID（比如通过 URL 参数 ?sid=abc123）。防御的关键是：用户真正完成身份认证后，服务端必须废弃原有会话，生成全新 session ID 并重置 Cookie。
- 前端无需生成或管理 session ID，也不应把登录前的 Cookie 当作有效凭证
- 登录接口返回成功后，浏览器会自动接收并替换新 Cookie（前提是后端正确 set-cookie）
- 若前端用 js-cookie 等库手动写入 sid，请立即删除——这会绕过 HttpOnly，反而引入风险
Cookie 必须启用三项基础安全属性
这些属性由后端在 Set-Cookie 响应头中设置，JS 不参与设置过程，但要确保不干扰其生效：
- HttpOnly：阻止 document.cookie 读取 session ID，XSS 脚本无法窃取
- Secure：仅在 HTTPS 下传输，防止中间人明文截获
- SameSite=Lax 或 Strict：限制跨站请求携带 Cookie，大幅降低 CSRF 和劫持利用面
注意：SameSite=None 必须搭配 Secure，否则现代浏览器拒绝设置；开发环境若无 HTTPS，可临时设为 SameSite=Lax + Secure=false，但上线前务必切回 Secure=true。
避免前端存储或操作敏感令牌
JavaScript 不该持有、解析或重写身份凭证类 Cookie：
- 禁止用
localStorage存 JWT 或 session ID —— XSS 可直接读取 - 禁止用
document.cookie = 'sid=xxx'手动设置 —— 绕过 HttpOnly，且易被篡改 - 如需前端读取非敏感状态（如语言偏好），可用 js-cookie 安全读取，但绝不用于权限判断
服务端配合：签名 + 短期有效期 + IP/UA 绑定（可选增强）
前端无法控制这些，但需理解它们如何与 Cookie 协同起作用：
- Cookie 值带 HMAC 签名（如
sid=abc123.hmac_xxx），服务端每次验证签名有效性 - 会话有效期不宜过长（如 30 分钟无操作即失效），降低被盗后利用窗口
- 高敏感场景可结合登录 IP 或 User-Agent 做轻量级绑定，异常变动时强制重新认证
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
