前言:HTTP是一种无状态协议,为了分辨链接是谁发起的,需要浏览器自己去解决这个问题,不然有些情况下即使是打开同一个网站的不同页面也都需要重新登录,而Cookie,Session,Token就是为了解决这个问题而来提出来的机制。

1.Cookie

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

Cookie为什么能够验证登录状态?那是因为cookie中放入了session_id参数或者token参数

cookie的分类:

1.Session Cookie:key,value形式,过期时间可设置,如不设置,则浏览器关掉就消失了,存储在内存当中,否则就按设置的时间来存储在硬盘上的,过期后自动清除。

当我们打开一个浏览器访问某个网站,该网站服务器就会返回一个Session Cookie,当我们访问该网站下的其他页面时,用该Cookie验证我们的身份。所以,我们不需要每个页面都登录。但是,当我们关闭浏览器重新访问该网站的时候,需要重新登录获取浏览器返回的Cookie。Session Cookie在访问一个网站的过程中,一般是不会变化的,有时候也会变化,比如,切换不同的权限的时候,Cookie值就会发送变化。
Session Cookie的生成和作用
在整个会话中,cookie是不会变化的,某些值会发生变化,例如靶场:DVWA不同等级之间用户的Session cookie
2.Permenent Cookie:Cookie的主要内容包括:名字 值 过期时间 路径 域
这是保存在浏览器客户端上存储用户信息的数据,Permenent Cookie是由服务端生成,然后发送给User-Agent,浏览器会将Cookie保到某个目录下的文本问价内,下次请求同一网站的时候就将该参数发送给服务器。

2.Session

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

1.浏览器第一次发起请求的时候,服务器自动生成了session(用户会话所需的属性及其配置信息)并且生成了session ID来唯一标识这个session,并将其通过响应发送到浏览器。浏览器第二次发送请求会将前一次服务器响应中的session ID放在请求的Cookie中一并提交到服务器上面,服务器从请求中提取出session ID 并和保存的所有session ID进行对比,找到这个用户所对应的session,从而知道了用户的登录信息,一般session ID会有时间限制,超时毁掉这个值。

2.当用户在应用程序的Web页间跳转时,也就是一次会话期间,浏览器不关闭,session ID一般是不变的。

Session ID除了可以保存在Cookie中,还可以保存在URL中,作为请求的一个参数(sid)

2.1Session的一些安全配置

1.session应该设置时效性,比如用户在短时间内未操作,即清除session
2.关闭浏览器,即清除session
3.如果应用为了用户体验,只要session一直在使用,则session不失效。这样,当用户cookie被盗了之后,无论该session活动与否,都强制清除session。
2.用户的IP,User-Agent变化了之后,强制清除session。

3.Token认证机制

Token是服务器端生成的用于验证用户登录状态的加密数据,和用session验证差不多,只不过Token验证服务器端不需要存储用户会话所需的配置等数据,只需要后端将Token进行验证签名,然后再发送给浏览器。所以,使用Token进行验证,在一次会话中,Token值是不变化的,这和session是一样的。

4.Token预防CSRF

上面利用Token验证是将Token值放在Cookie中用来验证用户登录状态,而我们现在要利用Token来预防CSRF的话,就不能将Token值放在CSRF中了,我们可以这样做:

当我们访问的网页中含有需要修改数据地方,后端服务器就会随机发送一个Token值给前端,然后我们修改完数据提交的请求包中,就会有该token字段,后端提取该token验证登录状态,当我们每次访问该网页或者其他修改数据的网页时,服务端返回的Token值都是不一样的,都是随机的,这样就可以预防CSRF。
关于SCRF的一些简述:https://www.shirong.ink/index.php/archives/1716/

5.Session认证和Token认证的区别

现在大多数网站用户认证都是基于 session 的,即在服务端生成用户相关的 session 数据,而发给客户端 sesssion_id 存放到 cookie 中,这样用客户端请求时带上 session_id 就可以验证服务器端是否存在 session 数据,以此完成用户认证。这种认证方式,可以更好的在服务端对会话进行控制,安全性比较高(session_id 随机),但是服务端需要存储 session 数据(如内存或数据库),这样无疑增加维护成本和减弱可扩展性(多台服务器)。 CSRF 攻击一般基于 cookie 。

基于 token 的用户认证是一种服务端无状态的认证方式,服务端不用存放 token 数据。用户验证后,服务端生成一个 token(hash 或 encrypt)发给客户端,客户端可以放到 cookie 或 localStorage 中,每次请求时在 Header 中带上 token ,服务端收到 token 通过验证后即可确认用户身份。这种方式相对 cookie 的认证方式就简单一些,服务端不用存储认证数据,易维护扩展性强, token 存在 localStorage 可避免 CSRF 。不过这种方式在加密或解密的时候会有一些性能开销(好像也不是很大),有些对称加密存在安全隐患(AES CBC 字节翻转攻击)。

最后修改:2022 年 03 月 20 日 11 : 17 PM
如果觉得这篇文章不错,不妨赏我碎银几两。