01 身份防线崩坏：认证与会话管理漏洞

01 身份防线崩坏：认证与会话管理漏洞

认证是“验证你是谁”，会话是“登录后继续承认你是谁”。认证与会话管理漏洞涵盖弱口令、明文或弱哈希存密码、可预测或可劫持的会话、缺失 HttpOnly 与 Secure、超时失效不当等问题，攻击者可借此顶替合法用户。防御以强口令加盐哈希、随机会话绑定身份、Cookie 加固、及时失效为核心。

第三幕从“你是谁”这道根本问题开讲。前面我们把输入当代码防，这一节面对的是另一种攻击——不碰代码，直接冲着你用来证明身份的那套凭证和会话动手。登录框人人都有，但做得对的人在少数，这正是它高风险的原因。

一、问题与直觉：凭什么相信你是你

登录成功后，Web 服务不能每次请求都让你重输密码，于是发一个会话令牌（通常是写在 Cookie 里的随机串），后续请求带上它就被认作“已登录用户”。问题集中在这条链条的三个薄弱点：凭证本身不牢（弱口令、明文存密码）、会话令牌不牢（可预测、可被读、不失效）、失信管理不严（超时过长、注销无效）。任何一环塌了，身份就被顶替。

认证层面哪里最容易漏，用一张“攻守对账表”最直观：左列是攻击者常用的破口，右列是防住它的那一步。

二、核心原理：三块失守面

凭证层：密码是第一个战场。若允许弱口令（123456）、默认口令不强制改，暴力破解与撞库很快见效；若把密码明文存库，一次拖库就全量送出门；若用弱哈希（如未加盐的 MD5），查表即可还原。正确的存法是单向强哈希加独有盐（如 bcrypt、scrypt、Argon2），同样的密码用不同盐得到不同哈希，查表失效。

会话层：会话令牌若可预测（自增、时间戳哈希），攻击者能猜中别人的令牌；若没设 HttpOnly，一次 XSS 就能用脚本读走；若不绑定身份或绑定过弱，拿到令牌就等于拿到身份。典范做法的要点是随机不可预测、写入带 HttpOnly 与 Secure、绑定到用户并定期轮换。

失效管理：超时设置过长让“一次登录终身有效”，注销不彻底让令牌仍可用，重设密码后旧会话不失效，都是常见的失信漏洞。敏感操作（改密、转账）前要求重验证身份，是成本可控的强兜底。

三、实际影响

身份防线崩的危害覆盖面最广：攻击者能冒充你改密码、看隐私、转账、以你的名义发内容；在客服系统里顶替管理员工号，还可能进一步越权到后台。因为身份几乎是所有业务动作的通行证，这一层失守往往是严重事故的起点。

四、工程实践要点

• 强口令策略：要求长度与复杂度，拒绝常见弱口令名单；对关键流程强制 MFA（多因素认证）。
• 加盐强哈希存密码：使用 bcrypt/scrypt/Argon2 这类带工作因子、抗 GPU 并行爆破的哈希，且每用户独有盐。
• 随机会话令牌：用密码学级随机源生成，不在 URL 暴露，写入带 HttpOnly 与 Secure 的 Cookie。
• 合理超时与及时失效：设置空闲超时与绝对超时；注销时服务端作废会话；敏感操作前重新验身份。
• 分级敏感：登录、支付、改密接口单独做防暴力破解（限频、验证码、延迟）。

⚠️ 常见坑：把“登录页防了暴力破解”误当安全完成。实际伤害更大的是会话管理与失效策略——一次 XSS 就能把 HttpOnly 缺失的会话偷走，哪怕你口令策略做得天衣无缝照样翻车。

五、一次完整的演练

背景：一个本地的登录演示应用，密码明文存库、未加 HttpOnly。操作（仅在隔离环境）：注册一个账号观察数据库明文；用开发者工具检查会话 Cookie 是否可被脚本读到。结果：明文存储 + XSS 窃取两条链路都走通。解读：明文使拖库即成泄露，无 HttpOnly 使脚本能取走令牌。变式：改为 Argon2 加盐存储并给 Cookie 加 HttpOnly，重复同样操作时，数据库里看不到明文、脚本读不到令牌，两条攻击路径同时失效。

六、多因素不是可选，是分摊

很多人把 MFA 当成“大厂或金融才需要”的配置。换个角度看：单靠“口令”这一道依据，一旦用户密码在别处的撞库中泄露，你的系统也跟着受害——用户在你这里没犯错，但密码在被盗那一边已经废了。MFA 等于把“知道口令”从充分条件降成必要条件之一，即便口令泄了，攻击者还差一截图、一设备或一验证码。所以别问“我要不要上 MFA”，要问“我哪条风险最高的路径先上”。登录口、改密口、支付口、管理后台，按触碰敏感面的大小排优先级逐条铺开，才是成本可控的分摊法。

七、一次“会话泄露”的现场还原

用真实事故推理一遍。现象：客服工单系统里一个客服工号突然收到了另一个客服的会话数据。排法：先查是不是令牌复用——登录日志里两个不同 IP 用同一会话令牌，多半是令牌被复制走；再查来源，最常见是把带令牌的 Cookie 或请求头贴进了工单、聊天记录，被日志或同事看到。结果定位在“会话令牌曾以明文形式出现在可被他人看到的记录里”。修复是三管齐下：令牌立刻轮换作废、把 HttpOnly 与 Secure 补上、在日志与客服工具里对令牌打码。这个案例的启示是，会话泄露很少是浏览器主动被黑，更多是“令牌混进了本不该出现的可见文本”这种低级却高频的失误。

本节要点回顾

• MFA 是分摊而非可选：把口令从充分条件降为必要条件之一，先铺最常触碰敏感面路径。
• 会话泄露常是令牌混进可见文本：轮换作废、HttpOnly、日志打码三管齐下修复。
• 认证验证你是谁，会话延续信任，两个战场都要守。
• 密码要强口令 + 加盐强哈希（bcrypt/scrypt/Argon2），明文或弱哈希违规。
• 会话令牌要随机、HttpOnly、Secure、绑定身份并轮换。
• 失效管理要合理超时 + 服务端注销 + 敏感操作重验身份。
• MFA、限频是关键流程的强兜底，别只盯着登录口。