ARTICLE · INTELLIGENCE

战地情报 · 详情页

来自尧图项目组的一线实战观察与深度解析

【Linux网络加餐】《HTTP 会话保持:Cookie 与 Session 原理及实验验证》---详解

【Linux网络加餐】《HTTP 会话保持:Cookie 与 Session 原理及实验验证》---详解

一.HTTP 会话保持

1.Cookie

HTTP 的特征如下:

  1. 简单快捷
  2. 无连接
  3. 无状态

HTTP 本身是无状态协议:协议层面不会保存客户端的历史访问信息,每一次 HTTP 请求都是独立的,服务器收到单次请求时,默认不知道这个请求来自哪个用户、之前有没有登录、浏览过哪些页面,请求和请求之间互相隔离、没有上下文关联。

但我们日常上网却有 “记住登录” 的体验,典型场景就是登录 CSDN 之后,关掉网页、甚至重启电脑,下次重新打开 CSDN 依旧保持登录状态,不用重复输入账号密码。这个能力并不是 HTTP 原生自带的,而是依靠Cookie来弥补无状态的缺陷。

Cookie 是服务器下发给浏览器、保存在本地的一小段文本数据。流程简单来说:

  1. 你第一次登录 CSDN,校验账号密码成功后,服务器通过响应头Set-Cookie,把携带身份标识的 Cookie 发给浏览器;
  2. 浏览器收到后,按域名保存这份 Cookie(可以设置过期时间,有的是会话 Cookie,关闭浏览器就失效;有的是持久 Cookie,会存到硬盘,重启电脑还在);
  3. 之后你每次访问 CSDN 对应的域名,浏览器都会自动在请求头里带上属于这个网站的 Cookie,一起发给服务器;
  4. 服务器读取 Cookie 里面的身份凭证,识别出你就是之前登录过的用户,直接放行,不用再次登录。

我们看到的这些 cookie 数据实际都是对应的服务器方写的,如果你将对应的某些cookie 删除,那么此时可能就需要你重新进行登录认证了,因为你删除的可能正好就是你登录时所设置的 cookie 信息。

得出结论:会话保持不是 HTTP 协议天然具备的特点,而是浏览器为了满足用户的使用需求,做了相应的工作。

那它到底是怎么实现的呢?

用户首次提交账号密码完成登录校验后,并不是浏览器直接保存用户名和密码。服务器验证信息无误后,会下发 Cookie 给浏览器保存。之后用户再次访问该网站、发起 HTTP 请求时,浏览器会自动把属于这个站点的 Cookie 放到请求头里,一同发送给服务器。服务器通过 Cookie 里的身份标识识别用户,所以在有效期内,不需要重复输入账号密码登录。

用来维持这种状态的技术就是 Cookie。Cookie 分为两类:会话 Cookie(内存 Cookie)和持久 Cookie(文件 Cookie)。


(1)引入 HTTP Cookie

a.定义

HTTP Cookie(也叫 Web Cookie、浏览器 Cookie,常直接简称 Cookie),是服务器下发到用户浏览器、并保存在浏览器本地的一小段数据。后续浏览器向同一个服务器发起请求时,会自动携带这份 Cookie 发送给服务端。 它的核心作用:让服务端识别多次请求是否来自同一个浏览器,典型场景就是维持用户登录状态、保存用户个性化偏好等。


b.工作原理

  1. 用户首次访问网站,服务器在 HTTP 响应头中添加Set-Cookie字段,把 Cookie 下发给浏览器;
  2. 浏览器收到 Cookie,按照域名分类保存在本地;
  3. 后续访问同源网站发起请求时,浏览器自动在 HTTP 请求头带上对应的 Cookie,发给服务器。

c.用途

  1. 用户认证与会话管理(最重要用途)
  2. 用户行为跟踪统计
  3. 缓存用户页面偏好、主题设置等

Chrome 浏览器快速查看 Cookie 地址:chrome://settings/cookies


e.HTTP 头部:Set-Cookie

Set-Cookie是响应头,由服务器返回给浏览器,浏览器识别后保存 Cookie。 基础语法:

Set-Cookie: <name>=<value>
  • name:Cookie 名称
  • value:Cookie 存储的值

完整示例:

Set-Cookie: username=peter; expires=Thu, 18 Dec 2024 12:00:00 UTC; path=/; domain=.example.com; secure; HttpOnly

f.时间格式规范

时间格式必须遵守RFC 1123标准,具体格式样例: Tue, 01 Jan 2030 12:34:56 GMT或者
UTC(推荐) 。关于时间解释

  • Tue: 星期⼆(星期⼏的缩写)
  • ,: 逗号分隔符
  • 01: ⽇期(两位数表⽰)
  • Jan: ⼀⽉(⽉份的缩写)
  • 2030: 年份(四位数)
  • 12:34:56: 时间(⼩时、分钟、秒)
  • GMT: 格林威治标准时间(时区缩写)

GMT 和 UTC 小科普(了解)

GMT(格林威治标准时间):基于地球自转,现在已经不再作为官方标准时间;

UTC(协调世界时):基于原子钟计时,精度极高,是网络、计算机系统通用的标准时间。 绝大多数场景下二者数值几乎一致,可以互换;高精度场景优先使用 UTC。


g.Set-Cookie 可选属性说明

表格

属性说明
expires=<date>设置 Cookie 过期时刻;不配置则默认是会话 Cookie,关浏览器失效
path=<路径>限制 Cookie 发送的路径范围,默认是当前设置 Cookie 的路径;path=/代表全站生效
domain=<域名>指定可以接收该 Cookie 的域名;带前缀.代表包含所有子域名
secure只有 HTTPS 请求才会携带这个 Cookie,防止在 HTTP 明文传输时被劫持
HttpOnly禁止前端 JS 脚本读取该 Cookie,用来防御 XSS 跨站脚本攻击

h.书写注意事项

  • 多个属性之间用;(分号 + 空格)隔开;
  • Cookie 的名称和值使用=连接;
  • 如果 name /value 包含空格、分号、逗号这类特殊字符,必须做 URL 编码。

i.Cookie 生命周期

  1. 配置expires:到达指定时间后 Cookie 自动过期失效;
  2. 未配置expires:属于会话 Cookie,浏览器进程关闭就销毁。

(2)内存级 Cookie 和文件级 Cookie

Cookie 是浏览器用来存储站点相关数据的载体,分为内存级 Cookie(会话 Cookie)和文件级 Cookie(持久 Cookie)。

  • 内存级 Cookie:保存在浏览器内存里,不会写入磁盘。一旦关闭浏览器进程,这份 Cookie 就会直接销毁。下次再打开网站访问,就需要重新登录。
  • 文件级 Cookie:以文件形式保存在本地磁盘中,带有指定过期时间。就算关闭浏览器、重启电脑,只要 Cookie 还没到期,访问网站时依旧有效,可以保持登录状态。

(3)Cookie 安全问题

如果本地存储的 Cookie 被攻击者窃取,不法分子就可以携带这份 Cookie,冒充我们的身份访问对应网站,这就是Cookie 劫持(Cookie 被盗取)。

为降低风险,我们可以把用户的核心登录信息存放在服务端,也就是Session。服务端会为每一个登录用户生成独立的 Session 数据,并分配唯一标识Session ID。服务器只把这个 Session ID 返回给浏览器,浏览器再把 Session ID 存进 Cookie 中。后续每次请求,浏览器自动带上 Cookie 里的 Session ID;服务器拿到 Session ID,去服务端查找对应的 Session 数据,完成身份鉴权。

这种方式下,用户真实信息不会放在 Cookie 里,避免敏感信息随 Cookie 泄露。安全防护还可以依靠服务端策略:比如检测到异地登录时,服务端主动让这个 Session ID 失效。失效之后,就算攻击者拿到 Session ID 也无法使用,网站会要求重新验证账号密码、短信或者人脸,以此确认操作者是本人,提升安全性。


(4) 实验测试cookie


Cookie 负责在客户端存储、传递 Session ID;Session 负责在服务端存放真实的用户会话数据,二者配合,就实现了 HTTP 无状态环境下的登录保持能力。


2.Session

(1)引入 HTTP Session

承接上文 Cookie,为后续登录验证流程做铺垫


定义

HTTP Session 是服务端用于跟踪用户、保存用户交互状态的机制。HTTP 本身是无状态协议,每一次请求相互独立,服务端无法自动识别请求归属哪个用户,所以依靠 Session 在服务端侧记录用户会话信息。


工作原理

  1. 用户首次登录访问站点,服务端为该用户生成全局唯一的Session ID;
  2. 服务端把 Session ID 通过Set-Cookie响应头下发给浏览器,由浏览器保存在本地 Cookie 中;
  3. 用户后续发起请求时,浏览器自动携带 Cookie 里的 Session ID;
  4. 服务端拿到 Session ID,查询对应的会话数据,完成用户身份识别;
  5. Session 的实际数据,一般存放在服务端内存、Redis 缓存或者数据库中。

安全性

Session ID 会在客户端和服务端之间传输,因此同样存在被窃取劫持的风险。 和直接把用户信息放进 Cookie 相比有明显优势:就算 Cookie 被盗,攻击者拿到的仅仅是 Session ID,用户的敏感信息本身保存在服务端,不会直接泄露。 同时服务端拥有更强的管控能力:例如检测到异地登录时,可以主动销毁对应 Session ID,使旧会话直接失效。 配套防护手段:使用 HTTPS 加密传输,同时给存放 SessionID 的 Cookie 设置HttpOnly、Secure属性,降低被窃取的概率。


超时与失效

  • 可以配置 Session 超时时间:长时间无操作,Session 自动过期失效;
  • 支持服务端主动销毁 Session:典型场景就是用户点击登出操作。

用途

  1. 用户身份认证与会话管理(核心用途)
  2. 临时业务数据存储,例如购物车、临时表单数据
  3. 分布式场景会话共享:把 Session 数据放到公共缓存 / 数据库,多台服务器可以共用同一份会话信息

(2)实验测试cookie

1.访问/login, 模拟登录


2.两个浏览器访问任意的站点资源

3.总结:

HTTP Cookie和Session都是⽤于在Web应⽤中跟踪⽤⼾状态的机制。Cookie是存储在客户端的,而Session是存储在服务器端的。它们各有优缺点,通常在实际应⽤中会结合使⽤,以达到最佳的用户体验和安全性。

RELATED READING

延伸阅读

更多一线实战笔记与深度复盘,助您持续精进