无状态

Q: 大家都知道HTTP是无状态的协议, 那怎么理解无状态呢?
A: 想象一下你们公司有个看门的门卫, 记性特别差, 还是个脸盲, 但是特别有职业操守, 每次出门回来都管你要出入证; 有一次, 你出门上厕所, 挺急的, 忘带了出入证, 回来他就把你堵门外边了, 这就是无状态;

那么按正常逻辑, 我把出入证弄个牌子挂脖子上不就行了, 每次他要看我就给他看, 不就好了; 麻烦了点, 但也行得通, 但要是如果他要的不是出入证而是身份证呢?你也把身份证做个牌子挂脖子上吗?这下好了, 你是能随便进了, 全公司甚至满大街都知道你身份证号了, 当然还有你家地址, 等着别人给你寄点年货吗?

实际上, 大多数的状态保持方案是为了保持用户的登录状态, 不用每次都麻烦用户重新输入用户名和密码, 一定程度上提高用户的使用体验

从为了方便的角度出发, 我们要把无状态变成有状态, 这个有状态并不是说让你们公司换个有眼力见儿的门卫, 而是直接把他KTV了, 弄个磁卡再弄个读卡机, 每次出入手一伸, 吧唧, 验证通过, 这个过程或动作就叫保持状态, 是不是既方便又安全呢

那保持状态常用的方案就来了: Cookie、Session和JWT

既然是现成的方案, 那自然是可以达到保持状态的目的, 但是上面例子中提到的隐私信息怎么处理呢?也就是说这三种方案的安全性又如何呢?

Cookie

Cookie可以直接翻译成曲奇饼干, 啥意思呢? 给你点甜头, 不用每次都输入用户名和密码, 在一定时间段内记住你是谁, 靠什么记住的呢? 当然就是例子里的磁卡了! 把用户名和密码存到磁卡里, 进门一扫, 读卡机一读, OK, 验证通过, 请进! 那也就是说Cookie本身就相当于是那张磁卡, 个人信息存放在其中, 那么磁卡放哪里呢? 当然, 每个人都会把磁卡放在自己的包里了, 想象一下, 你的书包就是浏览器或者叫客户端, 也就是说Cookie是保存在用户的本地的浏览器里的; 那么, 公司就相当于是服务器, 进入公司大门就相当于, 从浏览器中取出Cookie校验, 通过进门干活, 不通过打道回府; 那颁发Cookie也就很好理解了, 公司给你制作一张属于你的磁卡喽!

Session

Session我们可以对比Cookie进行理解, 假设我是隔壁公司的员工, 和你们公司的老王关系很好, 我想去你们公司偷一瓶水喝, 但是我进不去, 因为没有你们公司的磁卡; 有一天, 老王在上厕所时, 把磁卡放在了洗手池旁边, 于是, 我拿着老王的磁卡, 畅通无阻, 偷偷拿走了3瓶水, 给你们公司造成了大量的经济损失!然后我再把磁卡放回去, 是不是美滋滋呢, 关键是老王根本不知道发生了什么事, 哈哈哈
上面这个例子, 是不是暴露了Cookie的安全隐患呢? 我们常说的CSRF攻击, 就类似于这个情景
那么Session又是怎么保持状态的呢?
首先Session也有一张磁卡, 也就是Cookie, 但是它里头只存了Session-id, 也就是表示身份的一串东西, 而并没有保存敏感信息, 那敏感信息在哪里呢? 在你们公司小秘书的文件夹里呢想象一下,这个文件夹就是Redis数据库, 存放着真正有用的Session信息那么这个Session机制又是怎么运行的呢?
首先, 你拿着发给你的磁卡(里头存在你的Session-id), 去公司大门口一刷卡, 小秘书的电脑, 啵一下, 弹出了你的工号1024, 小秘书拿着文件夹(Redis)一翻, 1024号员工确有其人, 然后给了你一个把钥匙(Session), 你呢拿着这个钥匙, 找到了仓库大门, 打开仓库拿了瓶水, 这就是Session的机制
假设, 此时我3瓶水喝完了, 又一次故技重施, 是否还能成功呢?
答案是: 能!
因为小秘书,在玩王者荣耀, 根本没有看我的脸, 仅仅根据磁卡中的信息就把钥匙给我了, 我拿着钥匙打开了仓库大门, 又拿了3瓶水, 还有5包泡面, 再一次给你们公司造成了巨大的经济损失!

CSRF

啥是CSRF呢? 用上面的例子解释, 就是在老王不知情的情况下, 偷了老王的磁卡, 装作我就是老王, 进入了你们公司, 搞了一些事情;
CSRF全称Cross Site Request Forgery 跨站请求伪造
解释一下CSRF攻击的流程:
1.你登录某宝购物
2.某宝验证成功, 给你颁发了一个Cookie, 保存在了你的本地浏览器中
3.你在某破站看见了一个叫做赌怪的年轻人的视频, 于是技痒, 找到了澳门皇家赌城网站, 开始玩斗地主
4.在你疯狂的点击之下, 触发了这个钓鱼网站的非法链接, 钓鱼网站要求访问某宝, 并发送请求
5.浏览器根据钓鱼网站的请求携带你的Cookie去访问某宝, 成功验证, 采购了大量的扑克牌, 给你造成了巨额的经济损失
以上, 就是一个完整的CSRF攻击的流程, 你可能想问了, chrome浏览器是吃白饭的吗? 来着不拒吗? 我要卸载了你, 换一个最最好用的IE浏览器哦!对不起, 浏览器不背这个锅!那是谁的锅呢?用户又不都是程序员, 咱啥也不知道啥也不敢问啊…那自然是某宝没做好防护措施了, 这也就是我们在设计网站的时候要考虑防护CSRF攻击的原因了
那么, 不管你是用Cookie还是Session去实现保持登录, 你都会在浏览器中保存Cookie, 如此一来就有被CSRF攻击的风险, 那么怎么防护呢?
很简单, 你们老板发现, 卧槽, 最近我买的零食老是不翼而飞, 就问小秘书是不是你偷吃了, 小秘书一脸懵B, 老板调取监控录像, 发现有人冒名顶替, 于是决定增加一个验证手段, 刷脸, 磁卡中存一个照片, 进门时刷脸, 对上了可以通过, 对不上保安带走…于是乎, 我与老王的关系逐渐疏远了…
上面的小例子就是防护CSRF攻击的一种手段, 除非我整容, 否则永远无法再用老王的磁卡混入公司
那么怎么在网站中实现防护呢? 不能把用户的大头照存在Cookie中吧, 且不说Cookie容量有限, Cookie只能存字符串啊, 所以那咱就加个字符串不就完事了, 那添加的这个字符串我们就称之为Token令牌
防护原理: 请求参数中加入混淆字符串Token, Cookie中也加入Token, 后台从这两个地方分别取出Token碰一下, 如果一样, OK允许访问, 不一样就阻止访问
1.生成token, 存入浏览器Cookie中, 同时也存入页面表单中
2.用户请求, 后台从Cookie中取出token, 再从表单中取出隐藏字段token
3.对比两个token, 一致通过, 不一致阻止
因为token是随机生成的, 所以钓鱼网站无法获取, 伪造的请求只携带了Cookie到达正规网站, 但是并没有表单中的token, 不可能验证通过!

Json Web Token(JWT)

JWT的本质是T也就是Token, 所以一般也会简称为token, 只不过是形如JSON格式的token
那么介绍下JWT的三部分吧
第一部分: 头部 Header
保存了JWT的基本信息, 比如类型, 也就是"JWT", 签名所用算法等等, 是以JSON的格式存储的, 但是想要构成真正的头部, 还需要把这个JSON用base64转码, 转码后才能称之为头部
第二部分:载荷Payload
存放主要信息的地方就是载荷了,
iss: 签发者
sub: 所面向的用户
aud: 接收的一方
exp: 什么时候过期，Unix时间戳
iat(issued at): 什么时候签发的
这部分, 也需要使用base64转码, 转码后才能称之为载荷
第三部分:签名Signature
这个部分使用密钥secret进行加密，生成签名。
把base64加密后的头部和载荷, 再用秘钥进行二次加密, 二次加密的算法就是头部中声明的算法;
JWS的主要目的是保证了数据在传输过程中不被修改，验证数据的完整性。但由于仅采用Base64对消息内容编码，因此不保证数据的不可泄露性。所以不适合用于传输敏感数据。
有了Session为啥要还要使用JWT?
JWT存在哪? 本地浏览器的storage里
Cookie存在哪? 本地浏览器中
Session存在哪? 本地浏览器存Session-id, 服务器中存Session信息
1.正因为Session存在服务器, 随着网站运营时间的推移, 用户基数增大, 服务器需要分配大量的资源给Session机制, 甚至有的后台直接使用单独的一台机器就做保持登录状态; 而JWT存在用户自己的客户端, 不需要消耗服务器资源;
2.JWT不使用Cookie, 那自然就少了CSRF攻击的风险了;
3.Session存在服务器内存数据库中, 但是如果是分布式, 有许多台服务器, 在用户登录时, 需要在分布式服务器中查找对应的Session, 一定程度上会消耗分布式负载均衡的能力
JWT不存在Cookie里, 那我访问网站时, 怎么把JWT给后台呢?
答案: 放在请求头里, 从用户本地浏览器storage中取出JWT拼接成字符串, 存在请求头, 随请求一同传到后台, 是不是很方便呢?
最后让我们想象一下使用JWT的场景吧
你们公司老板觉得人脸识别太费钱, 想到了一个更好的方法, 磁卡不是会被盗用吗, 那我弄个不会被别人盗用的方法不就好了, 于是, 整了个指纹验证, 凭指纹进公司, 这样一来, 冒名顶替就被大概率避免了, 因为一般人想要复制指纹还是不大可能的; 当然了, 没有绝对的安全, 我们说的安全也都是相对意义上的安全, 如果恶意攻击者水平太高, 那啥样的防护也没有用, 这种情况, 直接找网络警察把他绳之以法, 相信他会没有好果子吃的!

什么是 Cookie Session 和 JWT相关推荐

熬夜彻底搞懂Cookie Session Token JWT
一切的根源就是因为 HTTP 是一个无状态的协议. HTTP 是一个无状态的协议什么是无状态呢?就是说这一次请求和上一次请求是没有任何关系的,互不认识的,没有关联的. 看过电影<夏洛特烦恼&g ...
js获取session_学习后端鉴权系列: 基于Cookie, Session认证
说起鉴权大家应该都很熟悉, 不过作为前端开发来讲, 鉴权的流程大头都在后端小哥那边, 但是作为一个有志气的开发者肯定要好好学习整个鉴权流程以及方案, 不然怎么跟后端合作. 常见的鉴权方案基于Cook ...
快速了解会话管理三剑客cookie、session和JWT
更多内容,欢迎关注微信公众号:全菜工程师小辉.公众号回复关键词,领取免费学习资料. 存储位置三者都是应用在web中对http无状态协议的补充,达到状态保持的目的 cookie:cookie中的信息是 ...
Cookie Session Token 与 JWT 解析
首先先了解一些关键词认证.授权与凭证什么是认证(Authentication)? 通俗地讲就是验证当前用户的身份是否合法的过程,即你是谁?证明"你是你自己"(比如:你每天上下 ...
转载：Session与JWT的使用
登录认证,估计是所有系统中最常见的功能了,并且也是最基础.最重要的功能.为了做好这一块而诞生了许多安全框架,比如最常见的Shiro.Spring Security等. 本文是一个系列文章,最终的目的是 ...
登录状态保持（cookie+session和token）
http设计之初,登录状态保持, 就是无状态的,这段时间业务逻辑也非常简单,随着互联网时代的来临,用户量的增加,每次登录却无法状态保持,先出现了cookie,但是cookie存储在客户端的浏览器上,并 ...
Cookie + Session登录-Token登录-SSO 单点登录-OAuth 第三方登录
文章目录 1.Cookie + Session 登录 2. Cookie + Session 存在的问题 3.Token 登录认证 1. Token 机制实现流程 2. Token 机制的特点 3. ...
代替Session的JWT
目录一.为什么不用Session用JWT 二.JWT结构三.JWT实现登陆的流程四.ASP.NET Core对于JWT的封装五.[Authorize]的注意事项六.解决JWT无法提前撤回的难 ...
【JavaWeb】认证授权（一）—— Session、JWT
文章目录 1.基础知识 2.实现 2.1Session 2.1.1基本实现 2.1.2添加过滤器 2.1.3上下文对象 2.2JWT 2.2.1基本实现 2.2.2添加拦截器 2.2.3上下文对象 1 ...

什么是 Cookie Session 和 JWT

无状态