token、session、cookie的一些理解以及移动端的验证流程来保证相对安全

-来去之间

已于 2022-07-25 10:35:19 修改

阅读量2.5k

点赞数 22

文章标签：安全服务器前端

于 2022-07-25 10:25:20 首次发布

本文链接：https://blog.csdn.net/qq_41103091/article/details/125969702

版权

首先先说Http协议，在最早的http 0.9只有Get请求因为最早的http协议只用于展示而不是用于和服务端进行交互

在Http协议1.0发布以后，里面就出现Post请求，但是此时每发一次Http请求都要进行一次三次握手四次挥手

在http1.1发布以后就出现使用Keep-Alive维持一个长连接，减少了每次发送Http握手过程产生的开销

Session

我们都知道Http协议是无状态的，不能保存登录的信息，当用户登录后再去请求其他网页的时候如果要验证用户是否登录这个时候我们该怎么办
Session就产生了，客户端将登录信息发给服务器，服务器进行验证，验证完成后，会返回一个Sessionid给客户端以及这个SessionID作用在哪个地方一般是通过一个Domian = localhost:8080 path:/userxx/xxx 这样来表示，也就是用户一旦范围这个uri下的url都会携带这个SessionID
在这里插入图片描述

服务器接收到客户端携带的SessionID就会去找这个SessionId所对应的一些数据例如用户信息等等，所以我们说Session是服务端的，那么SessionId是怎么存储的，一般我们可以存在Redis-Session中也可以直接用一个HashMap来进行存储，或者直接存进数据库。关于SessionId是怎么生成的，一般都是采用一个消息摘要算法对用户信息计算一个唯一值（MD5或者SHA等算法）
那SessionId在客户端是怎么存储的呢，这个时候就要用到Cookie来进行存储

Cookie

显而易见Cookie是客户端的，而不是服务端存储的，Cookie可以保存一些Session信息，是能够在浏览器保存的，并且持久化进本地磁盘，Cookie是可以设置过期时间（当然Session也能）

但是单纯的靠SessionID来记录登录信息显然是不安全的，一旦黑客截取了用户的SessionID 就可以把这个ID写进自己的浏览器Cookie中，然后去请求这个网页这个时候会显示已登录

在这里插入图片描述

Token

这个时候有出现了一样新东西，也就是token，token虽然不能保证浏览器端安全，但是在移动端被大量的使用，因为浏览器端是没有地方保存密钥的
注：现在的登录一般服务器数据库是不直接保存明文密码的，而是采用你注册的时候随机产生的一个唯一的salt值和你的登录信息（username、password）来计算一个MD5来验证是不是和密码字段的MD5值是否相等来判断是否登录成功
token的产生有很多种方案最简单的直接是uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign（签名，token 的前几位以哈希算法压缩成的一定长度的十六进制字符串
当然一般都会采用一个对称加密来生成这个token
这样说token好像和Session区别不大，但是我们可以发现Session会在服务端存储会话（临时性）信息，而token是直接采用查库的方式进行表示，但是用起来好像还是区别不大因为也可以把Session信息入库，因此在浏览器可以直接采用SessionID而不使用token，token一般是用在移动端比较多

Token 和 Session 的区别（别人写的）
Session 是一种
记录服务器和客户端会话状态的机制，使服务端有状态化，可以记录会话信息。
而 Token 是令牌，访问资源接口（API）时所需要的资源凭证。
Token 使服务端无状态化，不会存储会话信息。
Session 和 Token 并不矛盾，作为身份认证 Token 安全性比 Session 好，
因为每一个请求都有签名还能防止监听以及重放攻击，而 Session 就必须依赖链路层来保障通讯安全了。
如果你需要实现有状态的会话，仍然可以增加 Session 来在服务器端保存一些状态。
所谓 Session 认证只是简单的把 User 信息存储到 Session 里，因为 SessionID 的不可预测性，
暂且认为是安全的。而 Token ，如果指的是 OAuth Token 或类似的机制的话，提供的是 认证 和 授权 ，认证是针对用户，授权是针对 App 。其目的是让某 App 有权利访问某用户的信息。
这里的 Token 是唯一的。不可以转移到其它 App上，也不可以转到其它用户上。
Session 只提供一种简单的认证，即只要有此 SessionID ，即认为有此 User 的全部权利。是需要严格保密的，这个数据应该只保存在站方，不应该共享给其它网站或者第三方 App。所以简单来说：
如果你的用户数据可能需要和第三方共享，或者允许第三方调用 API 接口，
用 Token 。如果永远只是自己的网站，自己的 App，用什么就无所谓了。

移动端可以在手机本身就存储一个密钥因此移动端是能够比浏览器端更加安全的（为什么不能说绝对安全因为客户端的密钥可以通过逆向的手段拿到），因为这个特性，移动端比浏览器相对来说更加安全点

移动端安全解决办法：

服务器端
响应头增加随机字符串 CSRF_TOKEN=xxxxxxxxxxx（每次请求都不同且用完一次就返回一个新的）
客户端

客户端和服务端保留密钥 secret = yyyyyyyyy（可以采用对称加密或者非对称都可以）
客户端获取响应头CSRF_TOKEN下次请求必须携带
客户端（secret+提交内容）进行签名

当用户提交信息到服务器端，首先验证签名数据是否被篡改（防止被中间人攻击），随后通过token+随机字符串比对，正确的话执行操作，刷新随机字符串然后在response中返回给用户，即使token被中间人获取到了，没有随机字符串依旧执行不了任何操作，再糟糕点中间人通过拦截响应头获取到了随机字符串，
在这里插入图片描述