Cookie 与 Session 的区别（护网新人必看版），从零基础到精通，收藏这篇就够了！

Python_chichi

于 2025-04-24 17:14:52 发布

阅读量966

点赞数 23

文章标签： github 网络安全安全系统安全 web安全

本文链接：https://blog.csdn.net/Javachichi/article/details/147483170

版权

Cookie 和 Session，这对“老冤家”，简直是每个Web开发者和安全从业者的“噩梦”。搞不清它们？小心你的网站被人“扒光”！别怕，今天就用最“不正经”但绝对让你秒懂的方式，彻底搞定它们，顺便扒一扒护网时那些不得不防的“坑”。

超市“潜规则”：Cookie 和 Session 的那些“PY交易”

超市生存法则：小票和钥匙的“权责划分”

话说，第一次进黑心超市，收银员贼兮兮地给你一张“会员小票”（Cookie），上面印着你的“专属编号”（比如 VIP007）。下次来，只要亮出这张小票，就能享受“特殊服务”（比如打折、送鸡蛋啥的）。

存包的时候更刺激，你把宝贝疙瘩往储物柜一塞，机器立马“吐”出一把“钥匙”（Session ID），上面刻着“天字一号柜”。超市后台有个“秘密账本”（Session 存储），详细记录着哪个柜子存了啥、啥时候存的，这把钥匙就是打开账本的“通关密码”。
网络世界“暗语”：Cookie 和 Session 的“爱恨情仇”
- Cookie（浏览器里的“通缉令”）：当你第一次“光顾”某个网站，服务器会偷偷塞给你一个 Cookie，里面藏着你的“身份信息”（比如你是谁、登录了没）。就像你登录某宝，Cookie 里可能写着user=土匪; login=yes，下次再来，网站一眼就认出你这“老熟人”，省得你再输密码。
- Session（服务器的“秘密档案”）：你往购物车里扔了一堆“宝贝”，这些“宝贝”的详细信息（比如商品 ID、数量、价格）都藏在服务器的 Session 里。服务器通过 Cookie 里的 Session ID（比如session_id=一锅端），就能找到你的专属购物车账本，知道你都买了啥“好货”。

核心撕逼大战：Cookie vs Session，五大维度“扒皮式”对比（护网必看！！！）

“藏身之处”大PK：一个在你家，一个在别人家

Cookie（你家的小本本）	Session（黑心超市的账本）	护网老鸟为啥死盯这儿？
藏在你电脑/手机里（客户端）	藏在网站服务器里（内存/硬盘）	- 黑客能窜改你小本本上的信息（比如把你从“穷鬼”改成“土豪”）- 服务器账本太多，容易“爆仓”（Session 存太多数据，内存直接崩盘）
例：按 F12 就能看到Cookie: user=我是土匪	例：服务器日志里的Session ID: 一锅端	护网重点：Cookie 传输时有没有“穿马甲”（加密）？服务器账本的“保险柜”（权限）够不够硬？

“肚子里装的货”大比拼：小票只能记个号，账本啥都能写
- Cookie（小票只能写几个字）：最多塞进去 4KB 的信息（大概 1000 个汉字），而且只能是文本。你要是把密码明文写在上面，就像把银行卡密码贴在脑门上，黑客分分钟把你“洗劫一空”。
- Session（账本想写多少写多少）：理论上想存多少就存多少，还能存复杂数据。但别太贪心，当年某电商就是因为每个 Session 塞了 100 个商品，结果服务器直接“嗝屁”。
- 护网血泪教训：
  - Cookie 绝对不能碰敏感信息！曾经有个傻缺网站把密码扔进 Cookie，结果用户刚登录，黑客用 XSS 脚本直接把密码“偷”走了。
  - Session 也别太贪！存商品 ID 就够了，详情去数据库查，别把整个商品详情都塞进 Session 里，服务器会“闹肚子”的。
安全系数大PK：一个容易被“抄家”，一个藏得深

Cookie 的“雷区”	Session 的“陷阱”	护网老炮怎么防？
① 被 XSS 攻击“抄家”（黑客用脚本偷你小本本）	① 会话固定攻击（黑客提前给你配好钥匙，等你上钩）	- Cookie 穿上HttpOnly “防弹衣”：让浏览器禁止脚本读取，防 XSS 偷窥- Session ID 必须是“天书”（32 位随机数）：比如a1b2c3d4e5f6，别用1、2、3这种弱智编号
② 被手动“改头换面”（黑客篡改小票上的身份）	② 会话劫持（黑客偷了你的钥匙，直接进你家）	- Cookie 必须走Secure “高速通道”：只能 HTTPS 传输，防中间人窃听- Session 设个“门禁时间”：30 分钟不动自动注销，别让钥匙长期有效

“保质期”大PK：一个能存一年，一个默认关门就过期
- Cookie（长期饭票）：可以设置有效期，比如“7 天免登录”，直接存在你电脑硬盘里，7 天内访问网站自动登录。但保质期太长也危险，某银行 Cookie 设了 1 年有效期，结果用户电脑中毒，Cookie 被偷了一年，钱被盗刷 N 次。
- Session（临时身份证）：默认你关了浏览器，Session 就失效（钥匙作废），也可以设置有效期（比如 2 小时），存在服务器内存或文件里。但超时设置不合理也不行，某系统 Session 超时设 24 小时，管理员忘了退出，结果黑客半夜用 Session ID 登录，把数据“一锅端”。
- 护网血泪史：
  - 普通业务 Cookie 有效期别超过 7 天，敏感业务（如网银）设 1 天，而且登录后定期刷新 Cookie。
  - Session 超时时间看心情（根据业务定）：后台管理设 30 分钟，普通用户设 1 小时，防止钥匙被“捡漏”。
“互动方式”大PK：一个自动献殷勤，一个靠“暗号”接头
- Cookie（自动献殷勤）：你每次访问网站，浏览器自动带上对应的 Cookie，就像进超市自动掏会员卡，不用每次都证明“我是谁”。
- Session（靠“暗号”接头）：服务器通过 Cookie 里的 Session ID，找到对应的 Session 数据，就像你存包时给的钥匙编号，对应后台账本里的存包记录。
- 特殊情况：如果用户禁用 Cookie（比如开了隐私模式），Session 只能靠 URL 传 ID（如www.xxx.com?sessionid=123），但这样 URL 里的 Session ID 容易被钓鱼网站盯上（比如发链接http://xxx.com?sessionid=黑客伪造的ID）。

护网“潜规则”：四大核心漏洞攻防术（附带“实战演练”）

Cookie 篡改攻击：黑客“狸猫换太子”，冒充管理员
- 攻击套路：你登录后，Cookie 里有role=user（普通用户），黑客用 BurpSuite 抓包，把user改成admin，服务器没重新校验，直接让他进了管理员后台。
- 护网自检：① 登录后打开 BurpSuite，拦截请求，找到 Cookie 字段。② 把role=user改成role=admin，发送请求，看能否访问管理员功能（比如删除用户）。
- 防御姿势：
  - 服务器必须二次校验！别只看 Cookie，要查数据库确认用户角色（比如用户改了 Cookie，服务器查数据库发现他其实是普通用户，直接拒绝访问）。
  - Cookie 值必须加签名：比如用 HMAC 算法给role=user生成一个签名，黑客改了值，签名对不上，服务器直接拒绝。
Cookie 窃取攻击：XSS 漏洞“釜底抽薪”，偷走你的“身份证”
- 攻击套路：网站有 XSS 漏洞，黑客在评论区发，你的浏览器执行后，弹出 Cookie 内容，黑客通过钓鱼网站收集这些 Cookie，冒充你登录。
- 护网自检：在任何用户输入的地方（如搜索框、评论框），输入，如果弹出对话框，说明存在 XSS 漏洞，Cookie 可能被偷。
- 防御姿势：
  - Cookie 穿上HttpOnly “防弹衣”：写代码时加Set-Cookie: sessionid=123; HttpOnly，浏览器禁止脚本读取 Cookie，从源头防 XSS 窃取。
  - 输入输出必须过滤：把用户输入的<转成<，>转成>，让恶意脚本跑不起来。
Session 劫持攻击：黑客“顺手牵羊”，偷走你的“储物柜钥匙”
- 攻击套路：你用 HTTP 访问网站，Session ID 明文传输，黑客用 Wireshark 抓包获取sessionid=abc123，然后在自己的浏览器里伪造这个 ID，直接登录你的账号。
- 护网自检：用 Wireshark 抓包，过滤 HTTP 流量，看是否有JSESSIONID=或PHPSESSID=等字段，存在即说明 Session ID 明文传输，易被劫持。
- 防御姿势：
  - 强制 HTTPS 加密：部署 SSL 证书，Session ID 在 HTTPS 下加密传输，黑客就算抓包也是乱码。
  - Session ID 必须是“天书”：别用按顺序生成的 ID（如 1、2、3），用 32 位随机字符串（如d41d8cd98f00b204e9800998ecf8427e），让黑客猜不到。
Session 固定攻击：黑客“守株待兔”，提前给你挖好坑
- 攻击套路：黑客先访问网站，生成一个 Session ID（比如sessionid=黑客特制），然后发钓鱼链接给你，你点击后登录，你的会话就绑定了这个 ID，黑客用这个 ID 直接登录你的账号。
- 护网自检： ① 登录前记录 Session ID，登录后再次查看，正常情况应该更换新的 ID（防止固定攻击）。② 用 BurpSuite 发送带固定 Session ID 的请求，看是否能绕过登录验证。
- 防御姿势：
  - 登录后必须更换 Session ID：用户登录成功，服务器生成新的 ID，旧 ID 作废（相当于换一把新钥匙，旧钥匙失效）。
  - 定期刷新 Session ID：用户每次操作（如提交表单、刷新页面），服务器刷新 ID，增加黑客劫持难度。

护网“葵花宝典”：三大应用场景攻防细节，招招致命

记住密码功能：Cookie 是“先锋”，安全是“底线”
- 实现原理：你勾选“记住密码 7 天”，服务器生成一个加密的 Token（不是明文密码），存到 Cookie 里，有效期 7 天。
- 护网红线：
  - 绝对不能存明文！存加密后的 Token（如 AES 加密用户 ID + 时间戳），比如token=encrypted_123_20240501。
  - 必须加 Secure 属性： Cookie 里写Secure; SameSite=Lax，只能 HTTPS 传输，且禁止跨站发送，防中间人攻击和 CSRF。
购物车功能：Session 是“主力”，别太贪心
- 实现原理：你添加商品到购物车，商品 ID 和数量存在服务器的 Session 里，通过 Session ID 关联你的购物车。
- 护网经验：
  - Session 存 ID 就够了：别存商品详情（如图片、价格），只存商品 ID 和数量，详情从数据库查，减少服务器压力。
  - 设置合理超时： 30 分钟无操作自动清空购物车（session.gc_maxlifetime=1800），防止僵尸 Session 占内存。
跨页面会话：Cookie + Session 联手，严防“越权”
- 工作流程： ① 登录后，服务器生成 Session ID，通过 Cookie 发给你：Set-Cookie: JSESSIONID=abc123。② 你访问其他页面，浏览器自动带这个 Cookie，服务器用abc123找到你的会话数据。
- 护网铁律：
  - 检查 Cookie 作用域： domain=xxx.com别设成domain=.com，防止子域名拿到你的 Session ID。
  - Session 别存敏感数据：信用卡号、身份证号存数据库并加密，Session 只存必要的用户 ID 和权限等级。

护网“照妖镜”：Cookie 和 Session 的优缺点清单，一览无遗

场景	Cookie 更靠谱	Session 更给力	护网要盯紧啥？
轻量身份认证	✅ 自动携带，减轻服务器负担	❌ 服务器压力山大	Cookie 有没有加密？有没有藏着敏感信息？
复杂数据存储	❌ 容量有限，不安全	✅ 适合存购物车、登录凭证	Session 存储的“保险柜”（权限控制）够不够硬？超时设置合不合理？
长期登录状态	✅ 可设长期有效期（记住密码）	❌ 浏览器一关就失效	Cookie 有效期是不是太长了？有没有 HMAC 签名？
敏感操作（支付、改密码）	❌ 容易泄露，绝对不能存敏感信息	✅ 临时存储，用完就销毁	Session ID 是不是“天书”（随机）？有没有定期更换？

护网“三字经”：新手上路，牢记“三查四防”

日常巡检“三查”
- 一查 Cookie “装备”：有没有HttpOnly（防 XSS）、Secure（防窃听）、SameSite（防 CSRF）。
- 二查 Session ID “身世”：是不是随机生成（别用弱智编号）、登录后有没有“改名换姓”（更换新的 ID，防固定攻击）。
- 三查存储 “家底”： Cookie 有没有藏着明文密码、Session 有没有塞满垃圾（冗余数据，防内存溢出）。
漏洞防御“四防”
- 防篡改： Cookie 值必须加签名，服务器必须二次校验权限。
- 防窃取：强制 HTTPS 加密，Cookie 穿上HttpOnly “防弹衣”。
- 防劫持： Session ID 必须是 32 位随机数，禁止明文传输。
- 防固定：登录后必须更换 Session ID，定期刷新会话。