Cookie、Session和Token认证的区别联系

最新推荐文章于 2024-08-22 17:02:09 发布

whoim_i

最新推荐文章于 2024-08-22 17:02:09 发布

阅读量4.5k

点赞数 8

分类专栏：渗透测试

本文链接：https://blog.csdn.net/whoim_i/article/details/104279181

版权

渗透测试专栏收录该内容

38 篇文章 23 订阅

订阅专栏

发展史

在web发展初期，基本上就是一些文档的浏览，所以服务器不需要记录谁在某一时段里都浏览了什么文档，每次请求都是一个新的http协议，也就是请求加响应。随着交互式web应用的兴起，像一些在线购物网站，就会面临着一个问题，那就是对会话的管理。也就是服务器需要将每个用户单独的区分开，需要知道哪些资源属于哪些对应的用户，这对服务器来说就是一个不小的挑战，因为http请求时无状态的。于是会话标识（session id，一个随机字符串）就出来了，给每个客户端发送一个session id，这样就区分开了是哪个用户发起的请求了。
但是这样服务器就需要保存所有用户的session id，无疑给服务器带来了巨大的压力。如果有成千上万个session id，就会严重的限制服务器的扩展能力。比如说用两个机器组成一个集群，小明通过机器A登录系统，那么sessionId就会保存在机器A上，假设下一次请求被转发到机器B怎么办？机器B可没有小明的sessionId啊。有时候会采用session sticky的小技巧，就是让小明的请求一直粘连在机器A上。但是这也不管用，要是机器A挂掉了，还得转到机器B上去。这样的话就只好做session id的复制了，即把A机器上的session id复制到B机器上。后来memcached提出把session id集中存储在一个地方，所有机器都通过这个地方来访问。但是这样一来，一旦负责session的机器挂掉，所有人就得重新登录一遍，这种问题也是不愿意发生的。
于是就有人提出了摆脱session的想法。具体就是不在服务端保存sessionid了，让客户端去保存一个服务端生成的token，每次请求的时候附加上这个token，服务端只需要对这个token进行相应的校验就可以完成身份的验证了。比如说小明已经登录了系统，服务端给他返回了一个令牌（token），里面包含了小明的userid，下一次小明再通过http请求访问服务端的时候，就把这个token通过http的header带过来就可以了。
由于服务端不再存放sessionid了，也不会有token，那么可能就会有攻击者伪造token来做坏事。因此服务端需要对token做一些防伪造的的处理，具体就是对数据做一个签名。比如说用HMAC-SHA256算法加上一个只有服务器知道的密钥，对数据做一个签名，然后把签名和数据一起作为token，由于密钥别人不知道，就无法伪造token了。服务器并不会保存这个token，当小明再次将token发到服务器的时候，服务端会用同样的HMAC-SHA256算法和同样的密钥去对数据再计算一次签名，并和token中的签名做一个比较，如果相同的话，就可以判断出小明已经登陆过，并且可以直接取到小明的userId；如果不相同，则数据部分肯定被人篡改过，这时就能够做一些身份校验失败的相应处理。
这样一来，服务器就不需要保存sessionId了，只需要生成token，然后校验token，相当于用CPU计算时间换回了存储空间。

cookie

cookie是服务端发送给客户端的用于验证某一会话信息的数据，cookie中有很多字段。不同网站Cookie中字段是不一样的，是由服务器端设置的。Cookie中常放入session id 或者 token 用来验证会话的登录状态。

cookie分类

session cookie：当我们打开一个浏览器访问某个网站的时候，该网站服务器会返回一个session cookie，当我们继续访问该网站下其他页面时，用该cookie验证我们的身份。所以我们不需要每个页面都登录，但是我们关闭浏览器重新访问该网站时，需要重新登录获取浏览器返回的cookie。session cookie在访问一个网站的过程中一般是不变化的，有时也会变化，比如切换不同的权限时cookie值会变化。如下图session cookie的生成
在这里插入图片描述
permenent cookie：是保存在客户端浏览器上存储用户登录信息的数据，是由服务端生成发送给浏览器的。浏览器会将cookie保存在某个目录下的文本文件中，下次请求同一网站时就发送该cookie给服务器。前提是浏览器设置开启了cookie。如图为baidu.com下的cookie
在这里插入图片描述

session认证

session是保存在服务器端的经过加密的存储特定用户会话所需的属性及配置信息的数据。当我们打开浏览器访问某网站时，session建立，只要浏览器不关闭(也有时间限制，可以自己设置超时时间)，这个网站就可以记录用户的状态，当浏览器关闭时，session结束。
建立过程

客户端第一次请求网站时，服务端生成session并生成了session id来唯一标识这个session，并发送给客户端浏览器。
浏览器再次请求时将session id放在请求的cookie中一并发送到服务器，服务器从请求中提取出session id，通过对比找到这个用户对应的session，从而得知该用户的登录信息。一般session id有时间限制，超时后会被销毁，默认30分钟。
用户在应用程序的web页面间跳转时，也是一次会话期间，只要浏览器不关闭，session id不变。
如图这是我登录QQ邮箱时抓取的一个包

session id除了可保存在cookie中之外，还可以保存在url中，作为一个请求的参数（sid）

token认证

token是服务端生成的用于验证用户登录状态的加密数据，和session验证差不多。只不过token验证服务端不需要存储用户会话的配置数据。只需要将token进行验证签名再发给浏览器就行了。所以在一次会话中，token值是不会变化的。如图所示为token认证过程
在这里插入图片描述
如下图是登录QQ邮箱所发送的token

在这里插入图片描述
token的优势

无状态、可扩展。在客户端存储的Token是无状态的，并且能够被扩展。基于这种无状态和不存储Session信息，负载均衡器就能够将用户信息从一个服务传到其他服务器上。
支持移动设备。移动设备只需要有存储Token的能力，就能够使用这种身份验证的方式。
跨程序调用。只要用户有了一个验证通过的Token，数据和资源就能够在任何有相同校验规则的服务器（域）上请求到。
安全性较高。请求中发送Token而不再是发送Cookie，这样就能够防止CSRF（跨站请求伪造）。即使在客户端使用Cookie存储Token，Cookie也仅仅是一个存储机制而不是用于认证。Token是有时效的，一段时间之后用户就需要重新验证。

session认证和token认证的区别

现在大多数网站用户认证都是基于 session 的，即在服务端生成用户相关的 session 数据，而发给客户端 sesssion id 存放到 cookie 中，这样用客户端请求时带上 session id 就可以验证服务器端是否存在 session 数据，以此完成用户认证。这种认证方式，可以更好的在服务端对会话进行控制，安全性比较高(session id 随机），但是服务端需要存储 session 数据(如内存或数据库），这样无疑增加维护成本和减弱可扩展性(多台服务器)。
基于 token 的用户认证是一种服务端无状态的认证方式，服务端不用存放 token 数据。用户验证后，服务端生成一个 token发给客户端，客户端可以放到 cookie 或 localStorage 中，每次请求时在 Header 中带上 token ，服务端收到 token 通过验证后即可确认用户身份。这种方式相对 cookie 的认证方式就简单一些，服务端不用存储认证数据，易维护扩展性强， token 存在 localStorage 可避免 CSRF 。