Cookie 和 Session 的安全属性有哪些？登录态如何防盗用？

简化版

Cookie 常用于保存会话标识，安全关键是设置 HttpOnly、Secure、SameSite、合理的 Domain/Path 和过期时间。服务端 Session 要能过期、撤销、轮换，登录后重新生成 Session ID，防止会话固定和被盗用。

详细版

Cookie 本身只是浏览器按规则自动携带的键值数据，安全性取决于属性和服务端会话管理。HttpOnly 防止脚本直接读取 Cookie，Secure 限制只在 HTTPS 下发送，SameSite 降低 CSRF 风险，Domain/Path 控制发送范围。

服务端还要管理 Session 生命周期：登录成功后重新生成 Session ID，长时间不活跃要过期，退出登录要销毁，敏感操作可二次验证。如果使用分布式部署，Session 通常放 Redis 或数据库，避免只存在单机内存导致多实例不一致。

完整版教学

一、Cookie 和 Session 分别负责什么

Cookie 是浏览器保存并随请求发送的数据，Session 是服务端保存的登录状态。常见模式是 Cookie 里只放一个随机的 session_id，真正的用户 ID、权限、过期时间放在服务端。

浏览器 Cookie: session_id=abc123
服务端 Session: abc123 -> user_id=42, role=user, expire=30min

这样即使用户能看到 Cookie，也看不到完整用户信息。风险转移到了两个点：Cookie 不能被偷，Session ID 不能被猜中或固定。

二、HttpOnly 能防什么，不能防什么

HttpOnly 的作用是禁止 JavaScript 通过 document.cookie 读取该 Cookie。它能降低 XSS 后直接偷 Cookie 的风险，但不能阻止恶意脚本在同源页面里代用户发请求。

Set-Cookie: sid=abc; HttpOnly; Secure; SameSite=Lax

如果页面有 XSS，攻击者虽然读不到 sid，但仍可以调用 /api/transfer。所以 HttpOnly 是止损措施，不是 XSS 的根治方案。

三、Secure、SameSite、Domain 和 Path

Secure 要求 Cookie 只通过 HTTPS 发送，避免明文 HTTP 被窃听。SameSite 限制跨站请求携带 Cookie，常见值是 Lax、Strict、None。Domain 和 Path 决定哪些域名和路径会带上 Cookie。

属性	主要作用	常见坑
HttpOnly	JS 不能读取	不阻止同源请求
Secure	仅 HTTPS 发送	本地调试要区分环境
SameSite	降低 CSRF	None 必须配 Secure
Domain	控制子域共享	范围过大易被子域风险拖累
Path	控制路径范围	不是权限边界

记忆钩子：Cookie 安全属性管“浏览器什么时候带”，Session 管“服务端认不认这个身份”。

四、会话固定攻击是什么

会话固定是攻击者先拿到一个 Session ID，再诱导用户用这个 ID 登录。若服务端登录后不重新生成 Session ID，攻击者就能继续使用同一个 ID 访问用户账号。

1. attacker gets sid=known
2. victim logs in with sid=known
3. server binds sid=known -> victim
4. attacker reuses sid=known

防御方法是登录成功、权限提升、找回密码等关键节点重新生成 Session ID。旧 Session ID 要失效，不能同时保留。

五、Session 生命周期怎么设计

Session 不能永久有效。常见设计包括绝对过期时间、空闲过期时间、退出登录销毁、密码修改后踢下线、异常 IP 或设备变化重新验证。

空闲过期: 30 分钟无请求失效
绝对过期: 登录 7 天后必须重新登录
敏感操作: 10 分钟内重新验证

数字不是固定标准，要结合业务风险。银行、后台管理、普通内容站的会话期限不会一样。

六、分布式部署的 Session 存储

单机应用可以把 Session 放内存，但多实例部署时请求可能落到不同机器。登录态如果只存在 A 机器，下一次请求到 B 机器就会失效。

client -> worker A: sid exists
client -> worker B: sid missing

生产常用 Redis、数据库或签名 Cookie Session。服务端集中 Session 方便撤销，签名 Cookie 减少服务端存储但撤销更复杂。

七、排查登录态问题的顺序

线上遇到“明明登录了却变成未登录”，不要直接猜后端 bug。可以先看浏览器是否保存 Cookie，再看请求是否带 Cookie，再看服务端是否能查到 Session，最后看 Session 是否过期或被踢下线。

Set-Cookie 是否下发
Cookie 是否随请求携带
Session 存储是否命中
过期/撤销/多实例是否一致

如果是跨域登录，还要检查 SameSite=None; Secure、CORS 凭证配置和前端请求的 credentials。很多问题其实发生在“浏览器没有带 Cookie”这一步。

八、敏感操作的二次保护

普通页面浏览可以依赖登录态，但改密码、绑定手机、转账、删除数据等敏感操作，最好要求重新输入密码、MFA 或短期操作凭证。因为 Session 可能被借用，二次验证能降低账号被接管后的损失。

普通接口: session valid
敏感接口: session valid + recent auth within 10min

这不是重复登录，而是把高风险操作单独提高安全等级。

九、常见误区与追问

• 误区：HttpOnly 可以彻底防止 XSS 危害。 它只禁止脚本读取 Cookie，恶意脚本仍可发起同源请求。
• 误区：Session ID 放 Cookie 就一定安全。 还要配合 HTTPS、随机性、过期、轮换和撤销。
• 误区：Path 可以作为权限控制。 Path 只影响浏览器发送范围，服务端权限仍要校验。
• 追问：登录成功后为什么要换 Session ID？ 防止会话固定攻击。
• 追问：SameSite=Lax 能不能替代 CSRF Token？ 能挡很多场景，但关键操作仍建议 Token 或 Origin 校验。
• 追问：多实例 Session 放哪里？ Redis、数据库或其他共享存储。
• 追问：退出登录要做什么？ 删除客户端 Cookie，并让服务端 Session 立即失效。

十、加强记忆

Cookie/Session 安全可以按“两层”记：浏览器层用 HttpOnly + Secure + SameSite + 合理作用域 控制 Cookie 暴露和发送；服务端层用随机 Session ID、登录后轮换、过期、撤销、共享存储控制身份是否有效。Cookie 被偷是入口风险，Session 管理混乱是身份风险，两边都要管。