会话管理攻击：守住登录之后的身份连续性

上一章讨论认证机制时，我们一直在追问：系统凭什么相信屏幕前的人就是账号本人？认证成功后，这个问题没有消失，只是换了个问法：接下来的每一个请求，凭什么继续被当作这个人发来的？

HTTP 请求天然彼此独立。服务器不会因为你刚在上一个页面输入过密码，就自动记住下一次请求仍属于你。应用必须创建一段会话状态，再用一个会话标识把浏览器的后续请求和这段状态接起来。这个标识可能由 Cookie 携带，也可能是访问令牌或其他凭据。无论长什么样，只要服务器接受它，它在有效期内就接近一把临时钥匙。

也正因为如此，会话测试不是“偷一个 Cookie 看能不能登录”。我们真正要验证的是一组安全性质：标识是否难以预测，登录和提权时是否换钥匙，浏览器会在什么条件下发送它，服务器何时撤销它，异常使用能否被发现，以及分布式节点对“它已经失效”是否有一致认识。

会话保护的到底是什么

会话不是一个页面变量

你可以把一次已登录访问拆成三样东西：浏览器持有的会话标识、服务器保存的会话状态，以及每次请求到来时执行的验证逻辑。

浏览器通常只需要带上一个没有业务含义的随机值。服务器用它找到账号、登录时间、最近活动时间、信任等级和撤销状态等信息。若应用使用自包含令牌，一部分状态会放进令牌，但服务器仍然要验证令牌是否由可信方签发、是否用于当前系统、是否过期，以及是否已因安全事件而被撤销。

这里最容易产生误解的一点是：会话标识不是“用户编号的另一种写法”，而是一份短期的身份能力。用户名泄露通常只暴露账号名称；仍然有效的会话标识泄露，却可能让持有者跳过登录步骤。因此，标识不应出现在 URL、页面源码、分析事件、错误详情或常规日志中。

认证、会话与授权是三道连续检查

认证回答“你是谁”，会话管理负责把这个结论稳定地带到后续请求，访问控制再回答“这个身份能不能操作当前对象”。三者连在一起，却不能互相替代。

一个仍然有效的普通用户会话，不代表它能读取其他用户的订单；这属于下一章的访问控制。反过来，接口即使写了完善的资源权限判断，如果传入的身份上下文来自一个登出后仍有效、被固定或错误复用的会话，授权层得到的起点就已经错了。

测试时可以按两道门理解请求处理：第一道门验证会话本身是否可信，第二道门验证该身份是否有权执行当前动作。本章先把第一道门查清楚，下一章再继续检查第二道门。

风险由有效能力决定，不由字符串长相决定

有些 Cookie 只保存语言和主题，有些 Cookie 直接承载认证。不能看到缺少 HttpOnly 就把所有 Cookie 都判成账号接管，也不能因为令牌看起来像一大串乱码就认为它安全。

真正需要先确认的是：删掉或改变哪个载体会让测试账号失去登录状态；哪个载体可以换取新的访问令牌；哪个值只影响界面；哪个值会改变服务器认定的身份。会话测试从“盘点能力”开始，而不是从“盘点字符串”开始。

把会话画成一条状态机

很多看似分散的问题——登录后 Cookie 不变、登出后旧请求仍成功、页面一直不超时、修改密码后旧手机还能使用——其实都是状态转换没有收口。把会话按生命周期展开，测试重点会清楚很多。

匿名会话也有边界

用户还没登录时，应用就可能创建匿名会话，用来保存购物车、语言、登录流程随机数或设备偏好。这很常见。问题不在“登录前有没有 Cookie”，而在匿名状态能否被客户端挑选，以及登录后哪些内容会被迁移。

购物车商品可以按白名单迁移到新会话，账号身份、角色、认证结果和安全设置不能跟着一个匿名标识原地升级。一个稳妥的流程是：服务器使匿名标识失效，创建新的认证标识，再明确复制允许保留的业务字段。

信任变化就是换钥匙的时机

登录成功是最明显的边界，但不是唯一边界。完成多因素认证、切换到管理员模式、临时获得审批权限、修改密码、账号恢复后重新进入系统，都会改变会话所代表的信任程度。

每次信任等级发生实质变化，都要判断是否需要重新认证、更新标识、撤销关联会话或清除旧权限缓存。不要把“换标识”理解成只改浏览器里的 Cookie 值；服务器还必须让旧标识失去对应关系。

销毁必须发生在服务器

浏览器删除 Cookie 只是告诉这个浏览器“以后别再主动发送”。如果另一个副本仍能被服务器接受，安全边界就没有关闭。因此，主动登出、空闲超时、绝对超时、管理员撤销和账号风险处置都必须改变服务器端状态。

对服务端会话，可以删除记录或标记为撤销。对自包含令牌，则需要短有效期、撤销版本、令牌族状态或其他能让服务器拒绝旧副本的机制。只让前端清空本地存储，不能算完成撤销。

会话标识要像随机钥匙，而不是压缩过的用户资料

长不等于难猜

一个 64 个字符的标识，如果其中大部分来自用户名、时间戳和递增计数，仍然可能很弱。评估标识时要看有效随机性，而不是肉眼数长度。

新系统应优先使用成熟框架提供的会话生成能力，并让随机部分来自密码学安全随机源。有效熵至少应达到 64 位；自己设计新方案时，更稳妥的做法是直接生成至少 128 位随机值，再使用合适的文本编码。这样既不需要把账号资料塞进标识，也不用发明一套难以审查的算法。

如果测试需要观察多个样本，只能用测试账号在授权环境自行创建。先查看长度、字符集、重复情况和明显结构，再结合代码或框架配置确认生成方式。不要为了做统计而从生产流量批量收集真实用户令牌；那会让验证动作本身变成新的泄露面。

不透明标识更容易集中撤销

不透明标识本身没有业务含义，只是服务器会话仓库中的索引。用户编号、角色、到期时间和撤销状态都留在服务器端。它的优点是撤销直观，代价是需要可靠的共享会话存储。

自包含令牌把声明放进令牌并做密码学保护，适合某些分布式场景，但“能验证签名”不等于“可以永远信任”。验证端还要固定允许的算法，检查签发方、受众、有效期和令牌用途；对长期会话，还要有刷新令牌轮换、令牌族撤销和安全事件后的批量失效。

无论采用哪一种，都不要直接相信客户端单独提交的 role=admin、user_id=42 或 authenticated=true。客户端可以携带标识，身份和权限结论必须来自服务端可信状态，或来自经过完整验证且仍可受控撤销的声明。

只接受系统明确设计的传递通道

浏览器会话通常选择 Cookie，因为它能设置传输、脚本可见性和发送范围。应用即使平时使用 Cookie，也可能因为旧框架兼容而顺便接受查询参数、路径片段或表单字段里的会话标识。这个“顺便接受”会扩大固定与泄露风险。

URL 会被浏览器历史、访问日志、代理、截图、工单和跳转来源信息接触。把会话标识放在 URL 中，相当于让临时钥匙经过许多不需要处理密钥的系统。测试时应确认应用实际接受哪些通道；如果设计只允许 Cookie，来自其他位置的标识应被忽略，而不是悄悄生效。

陌生标识不能由服务器就地接纳

严格的会话管理只承认服务器自己创建过的标识。客户端递交一个从未签发的随机值时，服务器可以拒绝它，也可以另行生成新的匿名会话，但不能把这个陌生值直接登记成有效会话。

这个规则看起来很小，却直接切断了一条会话固定路径。测试时不需要枚举或爆破，只需在靶场里使用一个本地生成的无效占位值发起一次低风险请求，观察服务器是否拒绝或重新签发即可。

Cookie 属性是在划定浏览器的发送边界

Cookie 属性很重要，但它们解决的是不同问题。把 Secure、HttpOnly 和 SameSite 全写上，也不能自动修好服务器端不撤销、标识可预测或权限判断错误。我们先看一条常见的认证 Cookie 形态：

Set-Cookie: __Host-session=<随机值>; Path=/; Secure; HttpOnly; SameSite=Lax

这里的值只是占位符。真实测试记录应保留属性和脱敏指纹，不应抄下完整值。

Secure 限制传输通道

Secure 要求浏览器只在安全连接中发送 Cookie。站点已经部署 HTTPS，并不等于可以省略它。遗留的 HTTP 入口、错误跳转或同主机上的不安全内容，都可能让没有该属性的 Cookie 出现在明文请求里。

它也不是万能加密。终端被控制、浏览器扩展越权或应用脚本漏洞仍然可能造成会话滥用。完整防线还需要全站 HTTPS、合理的传输策略和对页面漏洞的修复。

HttpOnly 限制脚本读取，不限制浏览器代发请求

HttpOnly 会让页面脚本无法通过常见 Cookie API 直接读取该值，能降低脚本漏洞直接导出会话标识的风险。但脚本发起 fetch 或表单请求时，浏览器仍可能自动附带 Cookie。

所以看到 HttpOnly，准确结论是“页面脚本不能直接读取这个 Cookie”，不是“跨站脚本问题已经被解决”。恶意脚本依然可能读取页面内容、执行用户能执行的操作或改变安全设置。

SameSite 控制跨站携带条件

SameSite=Strict 限制最强，适合不依赖外部入口的敏感应用，但可能让邮件链接、联合登录回跳和跨站嵌入变得不顺。Lax 允许一部分顶层导航，在安全和可用性之间更容易落地。None 允许跨站携带，并且需要同时设置 Secure。

不要依赖浏览器的隐式默认值。不同环境对省略属性的兼容行为可能存在细节差异，产品应明确选择并测试。也不要把 SameSite 当作完整的请求伪造防线；需要跨站 Cookie 的业务仍应对状态变更请求使用独立防伪机制、来源检查和高风险再次认证。

还有一个容易混淆的细节：同站不等于同源。兄弟子域可能处于同一个“站”范围，却不是同一个源。若父域下存在安全水平较低的旧系统或用户内容站，只靠 SameSite 不能把它们和主应用隔离开。

Domain 与 Path 只决定发送范围

省略 Domain 时，Cookie 通常只返回给设置它的主机；显式设置父域会把范围扩大到相应子域。认证 Cookie 若没有跨子域共享的硬需求，就不应为了“以后可能用到”而放大范围。

Path 决定请求路径匹配时浏览器是否附带 Cookie。它能减少不相关请求携带敏感值，却不是权限机制。把 Cookie 限定在 /admin，不会让普通用户自动失去管理权限；服务器仍然必须验证角色和资源。

同一主机若存在多个同名、不同路径或不同域范围的 Cookie，服务器收到的请求未必带有足够信息说明每个值来自哪个设置范围，解析顺序也可能因组件不同而产生歧义。认证 Cookie 最好使用唯一名称和清晰范围，避免让代理、框架与应用各自猜一次。

Expires 与 Max-Age 只决定浏览器保存多久

没有 Expires 或 Max-Age 的 Cookie 通常被视为会话 Cookie；带上它们后，浏览器会按指定时间持久保存。若两者同时存在，Max-Age 优先。浏览器还可能恢复上次会话，因此“关掉窗口”不应成为服务器端过期策略。

客户端到期只会让浏览器停止主动发送。服务器仍要独立执行空闲超时、绝对超时和撤销检查。即使客户端时钟异常或旧值被手工保留，服务端也必须在自己的时间边界后拒绝它。

Cookie 前缀是浏览器护栏

__Host- 前缀要求 Cookie 来自安全连接，带有 Secure，使用 Path=/，并且不能设置 Domain。支持该规则的浏览器会拒绝不符合条件的设置，从而让主机边界更难被误配或覆盖。

前缀依然只是额外护栏。服务端必须按完整名称读取 Cookie，并保持撤销、超时和权限检查。还要考虑客户端兼容范围，不能把前缀支持当成唯一安全控制。

会话固定是一次失败的状态升级

会话固定和猜中随机标识不是一回事。它不一定攻破随机算法，而是利用登录前后没有换钥匙：某个匿名标识在用户完成认证后仍保持不变，并被原地赋予了账号身份。

想象匿名会话 A 只保存购物车。用户登录后，安全流程应创建认证会话 B，让 A 失效，再把允许保留的购物车数据复制过去。不安全流程则把 A 直接改成“已登录”。只要 A 曾被另一个控制者预先知道，登录动作就会把身份能力送到错误的钥匙上。

最小验证只看前后状态

在授权靶场中，一个测试账号和一个隔离浏览器容器就足以先验证核心属性。我们不需要诱导真实用户，也不需要把会话值发送给第三方。

证据写成“匿名指纹 a12f…，登录后指纹 93be…，旧上下文被拒绝”已经足够。报告附件没有必要变成一份可以直接复用的凭据清单。

修复必须覆盖所有信任入口

只在账号密码登录后调用一次“重新生成会话”还不够。短信登录、扫码登录、单点登录回调、账号恢复后的自动登录、多因素完成点和临时管理员模式都可能改变信任等级。

更稳妥的工程方式，是把会话更新收口到统一的身份状态转换服务中。每个入口只声明“信任从什么状态变到什么状态”，由统一逻辑负责签发新标识、迁移白名单状态、撤销旧标识和记录事件。

轮换时要处理并发与宽限窗口

真实页面会并发加载接口。若服务器一换标识就立刻拒绝全部旧请求，正常用户可能在切换瞬间遇到零星失败；若长期同时接受新旧标识，又会留下两把钥匙。

可以设计很短、单向且可观测的过渡窗口：旧标识只能完成已经开始的低风险请求，不能触发再次轮换或高风险操作，到点后彻底失效。实现还要防止两个并发请求分别产生两条长期有效的新分支。简单说，轮换可以有交接，但不能分叉成一棵没人管理的钥匙树。

会话劫持要从暴露、时长和处置一起看

会话劫持描述的是有效身份能力落入了错误控制者。来源可能是传输错误、页面脚本漏洞、恶意扩展、终端失陷、日志记录完整令牌、URL 泄露或运维误处理。评估时没有必要演示如何窃取别人的 Cookie，我们要检查的是系统怎样减少暴露，以及暴露后能否限制后果。

先减少令牌出现的位置

认证凭据只应出现在确实需要处理它的组件中。全站使用安全连接，认证 Cookie 设置合适属性，不在 URL 和页面脚本可读存储中放长期高价值令牌，不让代理与应用日志记录完整授权头，也不把原始请求随手贴进协作工具。

如果前端确实需要调用令牌，仍要明确它的寿命、作用域和刷新方式。浏览器本地存储容易被同源脚本读取，Cookie 则可能被浏览器自动随请求发送，两种方案都有不同代价，不能只凭一句“JWT 更安全”或“Cookie 更安全”做决定。

再缩短单个凭据的有效窗口

短期访问令牌、会话标识定期轮换、空闲超时和绝对超时解决的不是同一个问题，但会共同压缩旧副本的可用时间。对修改密码、删除多因素设备、账号恢复和异常登录等事件，还要主动撤销相关会话，而不是等它们自然过期。

设备和网络特征适合做风险信号

IP 地址、浏览器类型、粗略位置和访问节奏可以帮助识别异常，但很少适合被写成僵硬的唯一绑定条件。手机会在无线网络和移动网络之间切换，企业用户会共用代理，浏览器也会升级。只要地址一变就强制退出，误伤会很高；只要地址没变就完全信任，也挡不住共享网络里的滥用。

更合理的做法是组合多个信号：短时间出现不可能的远距离活动、同一会话在两个异常设备上并行、高权限刚提升就批量读取敏感数据、已撤销标识还在重复提交。低风险事件可以提醒，中风险要求再次认证，高风险再撤销会话并通知安全人员。

登出、超时、撤销和并发是一套结束策略

系统什么时候不再相信一条会话，不能靠一个“退出”按钮临时决定。产品需要把主动登出、自动超时、安全事件、远程撤销和并发会话写成同一套策略。

登出要同时关闭浏览器和服务器两端

登出响应可以清空 Cookie 或把它设为立即过期，让当前浏览器不再发送。真正决定结果的是服务器是否拒绝旧标识。测试时不要只看“退出成功”提示，也不要把浏览器后退显示的缓存页面直接当成会话仍有效；应刷新一个只读受保护页面，观察服务器响应。

单点登录场景还要把语义讲明白：“退出当前应用”“退出当前设备”“退出身份提供方”“退出所有关联应用”可能是四件不同的事。本地应用会话被撤销后，身份提供方仍有效，用户可能马上无感登录回来；身份提供方退出，也不一定自动通知所有已建立本地会话。测试结论要对照产品承诺，而不是凭按钮文案猜测。

空闲、绝对和轮换三个时钟不能混用

空闲超时从最后一次有效用户活动开始计时，减少用户离开设备后的暴露。关键在“有效活动”怎样定义：鼠标晃动、前端心跳、广告刷新和后台轮询不应轻易续命，否则页面放在那里就永远不会空闲。

绝对超时从会话创建开始计时，不管用户是否持续操作，到点都要求重新认证。它限制一条长期活跃会话的最长生命，不会被定时心跳绕开。

轮换周期只更新承载会话的标识，缩短单个标识连续有效的时间。它不会重置会话最初创建时间，也不能替代空闲和绝对超时。三个时钟都应由服务器执行；前端倒计时和到期提醒只负责体验。

具体时间没有一个适合所有系统的神奇数字。资金操作、医疗数据、后台管理和普通社区的容忍度完全不同。确定策略时要结合数据敏感度、典型任务耗时、共享设备风险和再次登录成本，再在测试环境把时间临时缩短进行验证。

安全事件要撤销完整的令牌链

用户修改密码、完成账号恢复、移除多因素设备或报告账号被盗时，系统应按风险决定撤销当前会话、其他会话或全部会话，并把选择清楚地告诉用户。

若架构使用短期访问令牌和长期刷新令牌，只撤销当前访问令牌没有意义。旧客户端可能拿刷新令牌换出新凭据。撤销策略要覆盖刷新令牌族、轮换产生的后代和已缓存的授权状态。常见做法是维护会话族状态或账号级安全版本，使验证端能识别“签发后发生过全局撤销”。

并发登录是策略，不是天然漏洞

一个账号同时在手机和电脑登录很正常。安全问题在于系统有没有明确回答：允许多少条会话，用户能否看到它们，新设备登录是否提醒，超过上限淘汰哪一条，能否单独撤销，高权限账号是否采用更严格规则。

如果策略允许并发，两条会话应有独立标识和独立撤销能力；退出手机不应误伤电脑，除非用户明确选择“退出所有设备”。如果策略只允许一条，新登录就应在服务器端使旧会话失效，而不是只在旧设备上显示一个遮罩。

分布式系统必须共享失效结论

多节点应用最怕“在 A 节点登出，在 B 节点仍然有效”。撤销状态、绝对到期时间和会话版本必须在验证路径上可见，并且有清楚的一致性目标。缓存可以提高性能，但不能让高风险撤销在未知时间内传播。

复测时要覆盖负载均衡后的多次请求、不同区域或网关，以及缓存重启后的行为。修复如果只删除单机内存中的会话，用户下一次被路由到另一台机器时，问题就会重新出现。

可观察的会话才容易及时止损

安全团队需要回答一组很具体的问题：这条会话何时创建，在哪次认证后获得当前信任等级，何时轮换，谁撤销了它，旧标识被拒绝过几次，敏感操作发生时会话处于什么状态。没有生命周期事件，事故调查只能靠猜。

记录事件，不记录秘密

适合记录的事件包括会话创建、登录完成、标识轮换、再次认证、权限提升、空闲或绝对到期、主动登出、远程撤销、批量失效、无效标识被拒绝，以及高风险处置结果。

日志需要关联同一条会话，但不能保存完整标识。可以在服务器受控环境中使用带密钥的摘要生成内部指纹，只将短指纹用于日志关联。普通无密钥哈希并不理想，因为令牌一旦进入其他数据集，仍可能被拿来对照。关联指纹也不能被浏览器当作新的认证凭据。

{
  "事件": "会话轮换",
  "账号": "测试用户-07",
  "会话指纹": "93be…",
  "信任变化": "基础登录到多因素完成",
  "旧标识结果": "已拒绝",
  "处置": "允许新会话继续",
  "环境": "授权测试"
}

密码、验证码、完整 Cookie、完整授权头、重置链接和页面个人信息都不应进入会话日志。日志往往保存更久、读者更多，记录秘密会让防守系统自己变成泄露源。

检测结果要能解释，也要能回滚

一条 IP 变化不足以证明劫持。检测规则应展示触发原因、使用了哪些信号、采取了什么动作。低风险可以增加审计或提醒用户，中风险要求再次认证，高风险才撤销会话或暂时限制敏感操作。

自动处置会影响真实用户，因此要有阈值、冷却时间、人工复核和回滚路径。处置本身也应写入日志，否则事后只看到“账号突然掉线”，无法判断是超时、管理员操作还是风控规则。

活动会话页是用户侧的处置面板

活动会话页可以展示设备类型、粗略位置、创建时间和最近活动，让用户识别自己的手机和电脑，并提供“退出此设备”“退出其他设备”等清楚动作。不要展示完整 IP、内部风控标签或任何令牌。

这个页面本身是高权限功能：用户只能管理自己的会话，客服只能执行被授权的协助动作，管理员代操作要经过再次认证和完整审计。到这里，会话管理就自然碰到了下一章的访问控制问题。

用最小动作完成授权靶场验证

会话测试很容易变成“不断改 Cookie 看会发生什么”。这种做法既难复查，也容易越过授权边界。更专业的方式是先写状态矩阵，再用最少请求验证每一个预期。

先准备范围、账号和停止条件

确认允许测试的主机、认证入口、账号角色、时间窗口、只读验证页面、禁止动作和异常联系人。使用与真实业务数据隔离的测试账号；涉及信任提升时，准备专用多因素设备或测试通道。

停止条件也要提前写：出现真实用户数据、验证码或锁定策略异常、测试账号权限超出预期、服务错误率上升、需要提高请求频率才能继续时，立即停下并联系范围负责人。

盘点载体和完整响应链

从首次打开登录页开始，记录每次响应设置或覆盖了哪些 Cookie，哪些只是偏好，哪些决定认证，是否还有授权头、刷新令牌或浏览器存储。不要只看最终页面，中间跳转也可能设置会话。

对认证载体记录名称、主机范围、路径、Secure、HttpOnly、SameSite、持久时间和前缀。值只保存本地短指纹。若需要截图，裁掉账号信息、完整 URL 参数和令牌列。

建立状态转换矩阵

矩阵的价值在于防止漏入口。主登录流程可能正确，扫码登录、联合登录回调或账号恢复却没有同样轮换。每一行都要能对应到产品定义，而不是测试者临场猜预期。

按低风险顺序执行

证据应证明控制，不应保留可复用凭据

一条合格证据通常包括测试前提、状态转换、属性截图、脱敏指纹、请求时间、只读接口响应、预期与实际差异，以及测试后清理结果。

不要写“成功劫持了用户”。更准确的表述是：“测试账号主动登出后，旧会话上下文仍能访问只读认证页面，说明服务器未立即撤销对应状态。”这句话说明了事实、范围和修复方向，又没有夸大到真实账号接管。

从发现问题到完成修复回归

会话问题的严重度取决于四件事：标识如何暴露、能保持多久、代表什么权限，以及旧状态能做什么。缺少一个 Cookie 属性不等于已经发生账号接管；登出后旧标识长期有效，也不能只写成“配置不规范”。报告需要把前置条件和实际能力说清楚。

修复优先处理服务器仍然信任的旧状态

第一优先级通常是让旧钥匙真正失效：修复登出和超时的服务端撤销，在认证与提权后更新标识，覆盖账号恢复和密码变化后的撤销链，保证所有节点得到一致结论。

第二优先级是缩小暴露面：为认证 Cookie 设置符合业务的发送属性，清理 URL、日志和脚本可读存储中的高价值令牌，收窄域范围与持久时间。

第三优先级是完善发现和处置：补齐生命周期事件、活动会话管理、异常登录提醒和高风险再次认证。监控不能替代修复，但能让其他漏洞造成令牌暴露时更快止损。

回归不能只重复最初那一条路径

修复后要覆盖密码登录、扫码或短信入口、联合登录回调、多因素完成点、权限切换、移动端、活动会话页和负载均衡节点。还要确认修复没有破坏正常流程：匿名购物车是否按白名单迁移，并发请求是否频繁掉线，联合登录是否循环跳转，后台轮询是否错误延长空闲时间。

最后再做一次横向检查：同一套会话服务被哪些应用使用，旧客户端是否仍接受过时通道，网关和缓存是否保留旧判定。会话问题常常修在一个入口、漏在另一个入口，只有沿生命周期复测，才能证明问题真正关闭。

章节检查

上一章确认身份，本章保证这个身份在后续请求中不会被旧标识、错误轮换和失效漏洞污染。下一章继续检查访问控制：当服务器已经知道请求属于谁，它是否只允许这个身份读取自己的对象、调用获准的功能，并在每一层都执行同样的权限判断。