Session , Cookie, Token

一个cookie的设置以及发送过程

http为无状态协议,用户的登录状态无法通过协议层面保存下来,因此一般使用icookie管理session

安全手段

cookie和表头其他字段共同管理session
你可能会说，居然攻击者能获得有效的session id,那么以他的水平，伪造一个相同的User-Agent不是件难事。不错，但是我们可以说这至少给他添加了一些麻烦，在一定程度上也增加了session机制的安全性。
你应该也能想到了，既然我们可以检查User-Agent这个头部来加强安全性，那么不妨再利用其它的一些头部信息，把他们组合起来生成一个加密的token，并且让客户端在后续的请求中携带这个token!这样的话，攻击者基本上不可能猜测出这样一个token是怎么生成出来的。这好比你用信用卡在超市付款，一个你必须有信用卡(好比session id)，另外你也必须输入一个支付密码(好比token),这有这两者都符合的情况下，你才能成功进入账号付款。
如果session id以及token都是通过GET数据来传递的话，那么对于能获取session ID的攻击者，同样就能够获取到这个token。所以，比较安全靠谱的方式应该是利用两种不同的数据传递方式来分别传递session id以及token。例如，通过cookie来传递session id,然后通过GET数据来传递token。因此，假如攻击者通过某种手段获得了这个唯一的用户身份标识，也是不太可能同时轻松地获取到这个token，它相对来说依然是安全的。

token作用

1 防止表单重复提交:

服务器端第一次验证相同过后，会将session中的Token值更新下，若用户重复提交，第二次的验
证判断将失败，因为用户提交的表单中的Token没变，但服务器端session中Token已经改变了。

2 防止SCRF

服务器端会对Token值进行验证，判断是否和session中的Token值相等，若相等，则可以证明请求有效，不是伪造的。