Linux --HTTP Cookie 与 Session

从一个问题开始B 站是怎么认识我的你有没有想过这样一个问题我打开 B 站输入账号密码登录。然后我刷新页面、点开一个视频、再点开另一个视频……B 站居然一直知道“我是我”知道我的昵称、头像、收藏夹。可是HTTP 协议是无状态、无连接的。无状态每个请求都是独立的服务器不会记得你上一次请求是谁。无连接每次请求响应后连接就断开了HTTP/1.1 虽然支持 keep-alive但本质仍是请求-响应模型。那服务器凭什么记住我答案就是Cookie 和 Session。HTTP Cookie服务器寄存在浏览器的小纸条什么是 CookieHTTP Cookie也叫 Web Cookie、浏览器 Cookie是服务器发送到用户浏览器并保存在浏览器上的一小块数据。它会在浏览器之后向同一服务器再次发起请求时被自动携带并发送给服务器。通俗理解Cookie 就像服务器给浏览器发的一张“小纸条”浏览器把它存起来下次再去同一家店服务器时自动把这张小纸条带上。工作原理三步走第一次访问服务器在响应的 HTTP 头中设置Set-Cookie字段把 Cookie 发送给浏览器。浏览器保存浏览器接收到 Cookie 后按照域名保存在本地。后续请求浏览器自动在 HTTP 请求头中携带Cookie字段把之前保存的 Cookie 发送给服务器。用一张简图表示浏览器 服务器 | ---- 第一次请求 --------- | | --- 响应 Set-Cookie ----- | | 保存 Cookie | | | | ---- 后续请求 Cookie ---- | | --- 响应 ---------------- |Cookie 的分类类型特点会话 CookieSession Cookie浏览器关闭时失效不设置expires或max-age持久 CookiePersistent Cookie带有明确的过期日期或持续时间可跨多个浏览器会话存在如果 Cookie 是持久性的它其实就是浏览器相关的、特定目录下的一个文件。但直接查看这些文件可能会看到乱码或无法读取的内容因为 Cookie 文件通常以二进制或 SQLite 格式存储。一般我们直接在浏览器对应的选项中查看即可。Cookie 的用途用户认证和会话管理最重要跟踪用户行为缓存用户偏好等比如在 Chrome 浏览器下可以直接访问chrome://settings/cookies查看和管理 Cookie。Cookie 的安全性由于 Cookie 是存储在客户端的因此存在被篡改或窃取的风险。这也是为什么后来引入了 Session。深入 CookieSet-Cookie 头部字段详解基本格式Set-Cookie: namevalue其中name是 Cookie 的名称value是 Cookie 的值。完整的 Set-Cookie 示例Set-Cookie: usernamepeter; expiresThu, 18 Dec 2024 12:00:00 UTC; path/; domain.example.com; secure; HttpOnly各属性详解属性描述usernamepeterCookie 的名称和值标识用户名为 peterexpiresThu, 18 Dec 2024 12:00:00 UTC指定 Cookie 的过期时间。在这个例子中Cookie 将在 2024 年 12 月 18 日 12:00:00 UTC 后过期path/定义 Cookie 的作用范围。这里设置为根路径/意味着 Cookie 对.example.com域名下的所有路径都可用domain.example.com指定哪些域名可以接收这个 Cookie。点前缀.表示包括所有子域名secure指示 Cookie 只能通过 HTTPS 协议发送不能通过 HTTP 协议发送增加安全性HttpOnly阻止客户端脚本如 JavaScript访问此 Cookie有助于防止跨站脚本攻击XSS时间格式RFC 1123 标准时间格式必须遵守 RFC 1123 标准具体格式样例Tue, 01 Jan 2030 12:34:56 GMT或者推荐使用 UTCThu, 18 Dec 2024 12:00:00 UTC各部分的含义Tue星期二星期几的缩写,逗号分隔符01日期两位数表示Jan一月月份的缩写2030年份四位数12:34:56时间小时、分钟、秒GMT格林威治标准时间时区缩写注意事项每个 Cookie 属性都以分号;和空格分隔。名称和值之间使用等号分隔。如果 Cookie 的名称或值包含特殊字符如空格、分号、逗号等则需要进行 URL 编码。Cookie 的生命周期如果设置了expires属性则 Cookie 将在指定的日期/时间后过期。如果没有设置expires属性则 Cookie 默认为会话 Cookie即当浏览器关闭时过期。单独使用 Cookie 有什么问题我们写入的是测试数据如果写入的是用户的私密数据呢比如用户名密码浏览痕迹购物车内容本质问题在于这些用户私密数据在浏览器用户端保存非常容易被人盗取。更重要的是除了被盗取还有就是用户私密数据也就泄漏了。所以我们需要一种更安全的机制Session。HTTP Session服务器端的“用户档案”什么是 SessionHTTP Session 是服务器用来跟踪用户与服务器交互期间用户状态的机制。由于 HTTP 协议是无状态的每个请求都是独立的因此服务器需要通过 Session 来记住用户的信息。通俗理解Session 就像服务器给每个用户建立的一份“档案”档案保存在服务器端用户手里只拿一个“档案编号”Session ID。工作原理首次访问服务器为用户创建一个唯一的 Session ID并通过 Cookie 将其发送到客户端。后续请求客户端携带这个 Session ID服务器通过 Session ID 识别用户从而获取用户的会话信息。存储位置服务器通常会将 Session 信息存储在内存、数据库或缓存中。用一张简图表示浏览器 服务器 | ---- 第一次请求 --------- | | --- Set-Cookie: sessionidxxx | | 保存 sessionid | 创建 Session 对象 | | | ---- 后续请求 Cookie: sessionidxxx ---- | | --- 响应 ---------------- | 通过 sessionid 找到 Session 对象安全性与 Cookie 相似由于 Session ID 是在客户端和服务器之间传递的因此也存在被窃取的风险。但是一般虽然 Cookie 被盗取了但是用户只泄漏了一个 Session ID私密信息暂时没有被泄露的风险。Session ID 便于服务端进行客户端有效性的管理比如异地登录。可以通过 HTTPS 和设置合适的 Cookie 属性如HttpOnly和Secure来增强安全性。超时和失效Session 可以设置超时时间当超过这个时间后Session 会自动失效。服务器也可以主动使 Session 失效例如当用户登出时。用途用户认证和会话管理存储用户的临时数据如购物车内容实现分布式系统的会话共享通过将会话数据存储在共享数据库或缓存中总结Cookie vs Session对比项CookieSession存储位置客户端浏览器服务器端安全性较低容易被篡改或窃取较高私密信息不直接暴露存储容量有限通常 4KB较大取决于服务器内存/数据库生命周期可设置过期时间会话 Cookie 关闭浏览器失效可设置超时时间服务器可主动失效用途用户认证、跟踪用户行为、缓存用户偏好用户认证、会话管理、存储临时数据跨域支持受同源策略限制通常通过 Cookie 传递 Session ID也受同源策略限制实际应用中Cookie 和 Session 通常会结合使用服务器创建 Session把 Session ID 通过 Cookie 发送给浏览器。浏览器后续请求自动携带 Session ID。服务器通过 Session ID 找到对应的 Session 对象从而识别用户。这样既利用了 Cookie 的自动携带机制又保证了私密数据存储在服务器端达到了最佳的用户体验和安全性。Session 比 Cookie 更安全说的是“存储位置和验证机制”更安全而不是说 Session ID 本身就绝对防盗。如果 Session ID 被黑客拿到了确实等于拿到了用户的“临时通行证”可以直接访问用户数据。这就像你家的门禁卡被人偷了别人也能进你家门。但为什么业界还是普遍认为 Session服务端存储比 Cookie客户端存储安全关键在于两者被盗的难易程度和被盗后的后果完全不同。我们可以从以下四个层面来拆解一、 核心差异Session ID 和 Cookie 里的“数据”不是一回事很多人混淆了“Session ID”和“Session 数据”。Cookie 方案客户端浏览器里存的往往是真实的用户信息比如用户ID、权限、甚至加密后的密码。如果 Cookie 被盗黑客不仅知道了你是谁还能直接看到你的隐私数据甚至可以伪造篡改如果加密不严。Session 方案客户端里存的仅仅是一个毫无意义的随机字符串Session ID。真实的用户信息用户名、购物车、权限全都存在服务端的数据库或内存里。安全优势即使黑客截获了 Cookie 中的 Session ID他也只能看到一个类似JSESSIONID8F7A3B...的乱码。他要想拿到数据必须拿着这个 ID 去服务端换。而服务端是有“门卫”的后面会讲。二、 黑客如何盗取难度天差地别你问“黑客也可以盗取 Session ID 直接访问”这没错但“盗取”这个动作本身难度极高。HTTPS 加密现代网站全站 HTTPSSession ID 在传输过程中是加密的黑客在公共 Wi-Fi 上抓包只能看到一堆乱码很难截获明文的 Session ID。HttpOnly 属性这是最关键的防御。服务端在设置 Cookie 时会加上HttpOnly标志。这告诉浏览器“这个 Cookie 只能用于网络请求JavaScript 绝对不许碰它” 这样即使黑客在网页里注入了 XSS 恶意脚本也无法通过document.cookie偷走 Session ID。相比 Cookie 存储真实数据如果你的 Cookie 里存了明文密码或敏感信息即使没有 XSS黑客通过浏览器漏洞或本地恶意软件也能直接读取。而 Session 方案在客户端什么都没留下黑客“无米下锅”。三、 服务端的“三重门禁”即使拿到 ID 也没那么容易假设黑客真的神通广大截获了你的 Session ID。你以为他能直接看数据服务端还有三道关卡绑定 IP 或设备指纹很多高安全系统会把 Session ID 和用户的 IP 地址、User-Agent浏览器标识绑定。黑客在北京用你的 ID 登录服务端发现 IP 不对直接判定为盗用踢下线或要求二次验证。短时效与自动过期Session ID 通常有过期时间比如 30 分钟不操作就失效。黑客拿到 ID 时可能这个 ID 已经凉了。单点登录限制如果系统检测到同一个 Session ID 在两个不同的地理位置同时活跃会立刻触发安全警报强制下线。四、 真正的“降维打击”Session 的“退出即销毁”Cookie尤其是 JWT方案有个致命弱点一旦签发在过期前无法作废。如果黑客偷了 JWT在过期前他都能一直用服务端甚至不知道他是黑客。而 Session 方案是有状态的。当你点击“退出登录”时服务端会把内存里的这个 Session 记录直接删掉。黑客手里的 Session ID 瞬间变成了废纸。如果管理员发现异常也可以在服务端一键踢掉某个用户的所有 Session。安全没有绝对只有“提高攻击成本”。Session 机制把攻击成本拉得比直接偷 Cookie 高得多这就是它被认为“更安全”的原因。