Session Management

 28th April 2021 at 5:56pm

这里的谈及的 session 主要针对 web server session。C/S 结构的程序（桌面端、移动端）也存在 session 机制，这在后面我接触到后再补充。

Wikipedia 上的定义：

In computer science and networking in particular, a session is a temporary and interactive information interchange between two or more communicating devices, or between a computer and user (see login session). A session is established at a certain point in time, and then ‘torn down’ - brought to an end - at some later point.

常见的使用场景

  • Login session：用户在登录网站时，在服务端生成一个 session 并将 session ID 给到客户端，于是用户之后的操作会带上 session ID，即表示已经在登录中的状态
  • Anonymous session：比如你在未登录状态下打开京东，将商品加入购物车，你刷新页面后会发现购物车中仍然有你加入的商品。这即是服务端为这个匿名会话存储了购物车物品

实现上，一般是服务端以 cookie 形式下发一个 session ID（aka. session token）给客户端，客户端在后续请求中会带上这个 ID，于是服务端即知道哪些请求是同一个用户发出的。这里的用户，即可惜是登录状态下的用户（此时服务端的 session 数据会带有用户在网站上的身份信息），也可以是未登录的用户（匿名用户）。

Session 本质上是把用户的部分应该在客户端上持久化的信息放在了服务端。比如：

  • 出于安全性考虑的登录态信息
  • 出于方便性考虑的购物车物品

但是你并非一定要用服务端的 session。有一些场景下，把信息放在浏览器的 local storage 或者 session storage 也是可行的。比如 QQ 音乐的 web 播放器，会把播放列表中的曲目信息存在 local storage 中。

基础概念

  • Session ID: 也称 session token，是服务端下发给客户端的一个 ID，客户端在后续请求中会带上这个 ID 标识自己
  • Session 数据：服务端上存储的关于某个 session ID 的数据，比如它对应的用户名

系统及功能设计

Session 系统及编程框架的设计，需要考虑下面这些点。

支持多种 engine 来存储 session 数据

比如数据库、缓存系统等。使用缓存系统时需要考虑 session 时效性。

支持多种 serializer 来序列化／反序列化 session 数据

比如 Django 默认用 JSON 来做序列化，但是 JSON 中没有 datetime 类型，同时 JSON 要求 value 必须是 unicode，不适合存储二进制数据。这种情况下可能需要定制 serializer。

支持定制 session 的有效时间

比如是一次性（关闭浏览器即失效）还是持续生效的。持续生效的可以持续多久。

Session 续期（renewal）／失效（invalidation）

存在一些需要延长 session 有效期，或者让它立即失效的场景。

续期：

  • 有些网站在用户有访问时会自动延长 session 有效期，方便用户使用
    • 对于这种场景，建议多开一个 session ID 表示一个固定的失效时间（比如用户登录 30 天后）。服务端应试同时查看这两个 ID 来判断登录态是否过期。这样可以避免某个用户的 session ID 被黑客获取后，黑客无限期地使用它的身份
  • 大多数网站出于方便，允许一个用户存在多个有效的 session；但是少部分网站出于安全性或者收费的考虑，仅允许存在有限的有效 session。比如网银只允许用户当前有一个登录，并且 10 分钟未操作可能会话就过期了。像收费观看内容的网站，根据收费策略可能限制了 session 数，使得你只能在有限台设备看它的内容，比如端传媒
  • Django 在 session 数据有变化时会自动延长有效期（仍不太理解这个设计）

失效：

  • 用户主动登出时，服务端应该将 session 失效
  • 用户修改密码时，该用户当前所有 session 都应该失效
  • OWASP 提到当用户的权限等级变化时（比如升级、从普通用户变为管理员等），应该重新生成 session ID。还不太理解它的用意

提供给用户查看当前未失效 session 的能力

比如 Google 提供了一个查看帐号已登录设备的 页面。它显示了设备类型（手机／PC）、操作系统、设备名和最近一次登录的地区。用户如果发现帐号被盗，可以将某一设备强行登出。

测试浏览器是否支持 cookie

有用户出于保护隐私关闭了浏览器 cookie 功能，可以提供一种机制来测试用户端是否支持 cookie，比如 Django 的 test cookies。

定时清理过期 session

对于主动登出的用户，服务器可以清除其 session；但是对于过期却没有登出的用户，需要定期从 session 存储中清除避免存储过度膨胀。

安全性考虑

可接受的 Session ID 交换机制

在客户端和服务端间交换 session ID 时，仅可以用 cookie 技术。有些老的框架用 URL 参数，这是非常不安全的，可能在 web server 的 access 日志等被泄露。

客户端及服务端的请求间应该开启 TLS。Session ID 的 cookie 应开启 secure flag 使其仅能在 HTTPS 形式下传输。并且应置 HTTP Only 防止被 JS 脚本获取。

SameSite 建议开成 Lax。Domain 及 Path 属性，视你的需求而设。

应当校验 session ID

客户端传输过来的 Session ID 是可以伪造的。应当像表单输入的参数一样做校验，防止被注入或者 XSS。

Session 存储

存 session 数据时应该同时加入一个加了盐及使用了不公开密码的 hash 值，防止存储被爆破 session 内容被随意修改。数据表中不应该将用户 ID 以明文存储在 session 存储中，这会导致黑客获得网站全部 session 数据后很容易发现它要攻击的用户的数据是哪一条。

防止浏览器缓存需要登录态才可查看的内容

使用 Cache-Control 和 Pragma 来指导浏览器不去缓存需要登录态才可查看的内容。避免 Session 过期后，一些敏感信息仍然能从浏览器缓存中被读取。

攻击检测和防御

攻击者做暴力破解时，可能需要用一批 IP 发大量请求。监控这类请求以及时发现。设置限流或者验证码来防止大量尝试。

防止用户 Session ID 被盗的另一个方法是，将 Session ID 与客户端的某些属性绑定在一起，比如客户端的地理区域、设备类型等。如果发现该 Session ID 相关的客户端属性发生变化，那即有可能是被盗取。

Session Hijacking and Session Fixation

Session Hijacking 是黑客通过手段获得用户 session key，使其可以伪装成用户。这一般通过 HTTP Only 的 cookie 等手段可以解决。

Session Fixation 是指黑客通过某种手段（CSRF、中间人攻击等）将其 session key 注入到用户的浏览器中，再诱导用户在目标网站登陆。一些 session 校验没做好的网站，在用户登陆后并不会更换 session key，因此用户跟黑客共享了一个 session key，从而实现攻击。

Django Session 实现

See Django: Session.

Resources

See Also