cookies, session, token

Cookie 是由客户端(通常是浏览器)保存的小型文本信息,其内容是一系列的键值对,是由 HTTP 服务器设置并保存在浏览器上的信息。

在post请求的瞬间,cookie会被浏览器自动添加到请求头中。

 

Session则是由服务器保存。

但是HTTP 协议是无状态的,也就是说当下一次用户发送请求的时候,请求中没有任何信息能表明用户身份!也就是说不知道请求是谁发出来了,这样也就不能认证了。

 

所以想到Cookie 来管理 Session,即生成一个SessionID, 放入 HTTP 响应中还给客户端,并保存在客户端,当客户端发送下一次请求的时候,就把这个 Sessionid 一起发送回来,这样就能知道请求是谁发出来的了

但是有几个问题:

1. 内存开销大

我们知道 Session 是存在服务器上的,实际上为了加快认证的速度,我们一般都会放在内存中,这样当用户基数大的时候,内存的开销就会很大。当然也可以将 Session 存入到 Session 表或者是缓存(redis等)中,但是依旧会有这样的问题。

2. 安全性(CSRF,Cross-site request forgery的缩写,跨站请求伪造)

因为是基于 Cookie 进行用户识别,如果 Cookie 被截获,用户就会很容易收到跨站请求伪造的攻击。

假如用户正在登陆银行网页,同时登陆了攻击者的网页,并且银行网页未对csrf攻击进行防护。攻击者就可以在网页放一个表单,该表单提交src为http://www.bank.com/api/transfer,body为count=1000&to=Tom。倘若是session+cookie,用户打开网页的时候就已经转给Tom1000元了.因为form 发起的 POST 请求并不受到浏览器同源策略的限制,因此可以任意地使用其他域的 Cookie 向其他域发送 POST 请求,形成 CSRF 攻击。

3. 分布式

因为 Session 信息是被单个服务器所保存的,所以在分布式系统中就不能适用了,多服务器不共享session。比如 Session 一开始是保存在 A 服务器上,但是下一次请求的时候,这个请求被服务器负载均衡转发到了 B 服务器,而 B 服务器则没有这个 Session 信息,所以就不能用过认证了。

 

 

这时候就考虑使用token。

token是开发者为了防范csrf而特别设计的令牌,浏览器不会自动添加token到headers里,攻击者也无法访问用户的token,所以提交的表单无法通过服务器过滤,也就无法形成攻击。

token 也称作令牌,由uid+time+sign[+固定参数]

组成

  • uid: 用户唯一身份标识
  • time: 当前时间的时间戳
  • sign: 签名, 使用 hash/encrypt 压缩成定长的十六进制字符串,以防止第三方恶意拼接
  • 固定参数(可选): 将一些常用的固定参数加入到 token 中是为了避免重复查库

存放

token在客户端一般存放于

1. localStorage

LocalStorage可以被 javascript 访问,所以容易受到XSS攻击。尤其是项目中用到很多第三方的Javascript类库。

2. cookie

优点:
可以指定 httponly,来防止被Javascript读取,也可以指定secure,来保证token只在HTTPS下传输。
缺点:
不符合Restful 最佳实践。
容易遭受CSRF攻击 (可以在服务器端检查 Refer 和 Origin)

需要cookie.setDomain("localhost"),如果不设置setDomain的信息的话,就会导致能成功登录,但 Cookies中没有任何的信息记录 ,也就是说不会将cookie保存在本地,虽然有set-cookie

相比较而言,Web Storage比Cookie更容易受到攻击。

3. sessionStorage中。

针对一个session的用户存储,也可以被javascript访问,但当用户关闭浏览器时,也会随之消失

 

JWT(Json Web Token)是一个跨域认证的方案。

 

 

posted @ 2019-10-22 16:42  *蓝医生*  阅读(213)  评论(0编辑  收藏  举报