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)是一个跨域认证的方案。