Cookie Session Token JWT & CSR

作者: baxiamali | 来源:发表于2019-12-10 17:52 被阅读0次

Cookie Session Token JWT & CSR
从session、cookie到token以及JWT
鉴权
基于token的登录认证
cookie、session、token、jwt
session、token、jwt、oauth2
有图有真相：带你实现现流行的权限验证
了解下常见的用户认证鉴权方式
鉴权的2种解决方案
区分Cookie、Session、Token、JWT

前言：

夏洛：大爷，楼上322住的是马冬梅家吧？
大爷：马都什么？
夏洛：马冬梅。
大爷：什么都没啊？
夏洛：马冬梅啊。
大爷：马什么没？
夏洛：行，大爷你先凉快着吧。

基于 http 协议的 web 应用程序是请求——应答模式是无状态的，我们可以这样理解：每次的请求都是独立的，它的执行情况和结果与前面的请求和之后的请求是无直接关系的，它不会受前面的请求应答情况直接影响，也不会直接影响后面的请求应答情况。
为了让Web服务器有记忆，有状态，有以下几种方法。

Cookie

浏览器第一次访问服务端时，服务器此时肯定不知道他的身份，所以创建一个独特的身份标识数据，格式为key=value，放入到Set-Cookie字段里，随着响应报文发给浏览器。
浏览器看到有Set-Cookie字段以后就知道这是服务器给的身份标识，于是就保存起来，下次请求时会自动将此key=value值放入到Cookie字段中发给服务端。
服务端收到请求报文后，发现Cookie字段中有值，就能根据此值识别用户的身份然后提供个性化的服务。

image.png

Cookie就是服务器委托浏览器存储在客户端里的一些数据，而这些数据通常都会记录用户的关键识别信息。所以Cookie需要用一些其他的手段用来保护，防止外泄或者窃取，这些手段就是Cookie的属性。

参数名	作用	后端设置方法
Max-Age	设置cookie的过期时间，单位为秒	cookie.setMaxAge(10)
Domain	指定了Cookie所属的域名	cookie.setDomain("")
Path	指定了Cookie所属的路径	cookie.setPath("");
HttpOnly	告诉浏览器此Cookie只能靠浏览器Http协议传输,禁止其他方式访问	cookie.setHttpOnly(true)
Secure	告诉浏览器此Cookie只能在Https安全协议中传输,如果是Http则禁止传输	cookie.setSecure(true)

Path

设置为cookie.setPath("/testCookies")，接下来我们访问http://localhost:8005/testCookies，我们可以看到在左边和我们指定的路径是一样的，所以Cookie才在请求头中出现，接下来我们访问http://localhost:8005，我们发现没有Cookie字段了，这就是Path控制的路径。

Domain

设置为cookie.setDomain("localhost")，接下来我们访问http://localhost:8005/testCookies我们发现下图中左边的是有Cookie的字段的，但是我们访问http://172.16.42.81:8005/testCookies，看下图的右边可以看到没有Cookie的字段了。这就是Domain控制的域名发送Cookie。

Session

Cookie是存储在客户端方，Session是存储在服务端方，客户端只存储SessionId

image.png

@RequestMapping("/testSession")
@ResponseBody
public String testSession(HttpSession session){
    session.setAttribute("testSession","this is my session");
    return "testSession";
}


@RequestMapping("/testGetSession")
@ResponseBody
public String testGetSession(HttpSession session){
    Object testSession = session.getAttribute("testSession");
    return String.valueOf(testSession);
}

我们在请求参数中加上HttpSession session，然后再浏览器中输入http://localhost:8005/testSession进行访问可以看到在服务器的返回头中在Cookie中生成了一个SessionId。然后浏览器记住此SessionId下次访问时可以带着此Id，然后就能根据此Id找到存储在服务端的信息了。

image.png

过期时间：

客户端：和Cookie过期一致，如果没设置，默认是关了浏览器就没了，即再打开浏览器的时候初次请求头中是没有SessionId了。
服务端：服务端的过期是真的过期，即服务器端的Session存储的数据结构多久不可用了，默认是30分钟。

Session是存储在Tomcat(以此为例)的容器中，所以如果后端机器是多台的话，因此多个机器间是无法共享Session的，此时可以使用Spring提供的分布式Session的解决方案，是将Session放在了Redis中。

Token

Session是将要验证的信息存储在服务端，并以SessionId和数据进行对应，SessionId由客户端存储，在请求时将SessionId也带过去，因此实现了状态的对应。而Token是在服务端将用户信息经过Base64Url编码过后传给在客户端，每次用户请求的时候都会带上这一段信息，因此服务端拿到此信息进行解密后就知道此用户是谁了，这个方法叫做JWT(Json Web Token)。

image.png

Token相比较于Session的优点在于，当后端系统有多台时，由于是客户端访问时直接带着数据，因此无需做共享数据的操作。

Token的优点

简洁：可以通过URL,POST参数或者是在HTTP头参数发送，因为数据量小，传输速度也很快
自包含：由于串包含了用户所需要的信息，避免了多次查询数据库
因为Token是以Json的形式保存在客户端的，所以JWT是跨语言的
不需要在服务端保存会话信息，特别适用于分布式微服务

CSRF攻击

image.png

可以这么理解：有一个人发给你一个搞(mei)笑(nv)图片链接，你打开这个链接之后，便立刻收到了短信：你的银行里的钱已经转移到这个人的帐户了。

1.登录受信任网站A，并在本地生成Cookie。
2.在不登出A的情况下，访问危险网站B。

CSRF 攻击的对象

在讨论如何抵御 CSRF 之前，先要明确 CSRF 攻击的对象，也就是要保护的对象。从以上的例子可知，CSRF 攻击是黑客借助受害者的 cookie 骗取服务器的信任，但是黑客并不能拿到 cookie，也看不到 cookie 的内容。另外，对于服务器返回的结果，由于浏览器同源策略的限制，黑客也无法进行解析。因此，黑客无法从返回的结果中得到任何东西，他所能做的就是给服务器发送请求，以执行请求中所描述的命令，在服务器端直接改变数据的值，而非窃取服务器中的数据。所以，我们要保护的对象是那些可以直接产生数据改变的服务，而对于读取数据的服务，则不需要进行 CSRF 的保护。比如银行系统中转账的请求会直接改变账户的金额，会遭到 CSRF 攻击，需要保护。而查询余额是对金额的读取操作，不会改变数据，CSRF 攻击无法解析服务器返回的结果，无需保护。

当前防御 CSRF 的几种策略

验证 HTTP Referer 字段
服务器验证Referer 字段，如果不是受信网站则拒绝请求。

问题：使用验证 Referer 值的方法，就是把安全性都依赖于第三方（即浏览器）来保障，从理论上来讲，这样并不安全。事实上，对于某些浏览器，比如 IE6 或 FF2，目前已经有一些方法可以篡改 Referer 值。如果 bank.example 网站支持 IE6 浏览器，黑客完全可以把用户浏览器的 Referer 值设为以 bank.example 域名开头的地址，这样就可以通过验证，从而进行 CSRF 攻击。并且用户可以设置不使用Referer。非100%安全。