CSRF、Cookie、Session和token之间不得不说得那些事儿

文章目录

• 1. 前言
• 2. 什么是CSRF？
• 3. 什么是Cookie？有什么用？机制？
• 4. 什么是session？有什么用？机制?
• 5. 什么是token？有什么用？它有什么特点？为什么能防止CSRF？
• 6. 总结
• 7. 参考文献

1. 前言

web开发相关职位的面试中，经常会遇到CSRF、Cookie、Session和token。每次看了一些博客之后，总是以为理解了，燃鹅事情并不是这样。

强烈推荐大家先读一读这篇博客，真的写的很好。彻底理解cookie，session，token

2. 什么是CSRF？

原文 安全|常见的Web攻击手段之CSRF攻击

CSRF攻击的全称是跨站请求伪造（ cross site request forgery)，是一种对网站的恶意利用。

简单点讲就是，恶意网站(攻击者)盗用了你的身份，以你的名义向信任网站发送恶意请求。

CRSF能做的事情包括利用你的身份发邮件、发短信、进行交易转账等，甚至盗取你的账号。图片来自什么是CSRF？可能多数人都不清楚，没事，一起来了解！！！

对上面的图进行分析：

1. 用户C通过浏览器登陆并浏览信任网站A；
2. 在用户C的浏览器中生成网站A的Cookie；
3. 用户C通过浏览器访问恶意网站B；
4. 在恶意网站B的一些HTML标签或者js中有一些代码，让用户C去访问网站A(发送用户C对网站A的request)，进行一些恶意操作；例如：

   　银行网站A，它以GET请求来完成银行转账的操作，如：
   　http://www.mybank.com/Transfer.php?toBankId=11&money=1000危险网站B，它里面有一段HTML的代码如下：
   　<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>
              

5. 此时，这个request请求会携带网站A的Cookie去请求网站A；
6. 网站A无法识别请求是否是用户的请求，还是恶意网站盗用身份后的请求，所以会按照请求内容进行操作。

需要知道的就是，

在恶意网站的HTML或者JS代码中会让你去访问其它网站，你的浏览器在访问网站的时候会自己携带该网站的Cookie去请求，然而网站对于用户的认证信息都在Cookie里，所以才让恶意网站有机可乘。

3. 什么是Cookie？有什么用？机制？

原文 深入理解Cookie

由于HTTP协议本身是无状态的，也就是说同一个用户前一次HTTP请求和后一次HTTP请求时相互独立的，无法判断后一次请求的用户是不是刚才的用户。为了记录用户的状态，才有了Cookie。

Cookie实际上以key-value键值对的形式存储了一些文本信息数据，它将数据保存在客户端(浏览器)。

当浏览器(客户端)登陆网站请求服务器后，服务器的response中返回了Set-Cookie（与Cookie类似，也是键值对的一小段文本），浏览器(客户端)将这个Cookie保存起来，当下次该浏览器(客户端)再请求此服务器时，浏览器(客户端)把请求的网址连同该域的Cookie一同提交给服务器。服务器检查该Cookie，以此来辨认用户状态。

1. 客户端发送一个HTTP Request请求服务器；
2. 服务器方返回一个HTTP Response给客户端，其中有Set-Cookie的头部；
3. 客户端根据Set-Cookie将该网站的Cookie保存下来；
4. 当再次请求该服务器时，浏览器客户端会自动携带已经保存的该网站的Cookie一同发送给服务器；
5. 服务器返回HTTP Response；

Cookie中通常包含的信息：

Cookie属性	描述
Name	设置要保存的 Key
Value	设置要保存的 Value
Domain	生成该 Cookie 的域名，如Domain=“www.csdn.net”
Path	该 Cookie 是在当前的哪个路径下生成的，如Path=/blog/
Expires/Max-Age	过期时间，超过该时间，则Cookie失效
Size	Cookie大小
HttpOnly	如果Cookie中设置了HttpOnly属性，那么通过js脚本将无法读取到cookie信息，这样能有效的防止XSS攻击，窃取Cookie内容，这样就增加了Cookie的安全性
Secure	如果设置了这个属性，那么只会在 HTTPS 连接时才会回传该 Cookie
SameSite	如果链接来自外部站点，浏览器不会将cookie 添加到已通过身份验证的网站。

所以Cookie的作用就是保存用户状态，让服务器能够知道这一次请求的用户是谁，他有哪些信息。

需要注意的是，由于同源策略的存在，不同源的网站不能使用对方网站的Cookie，也即是不可以跨域名的，隐私安全机制禁止网站非法获取其他网站的Cookie。

所以，在CSRF中恶意网站其实并不能获取到信任网站的Cookie。

4. 什么是session？有什么用？机制?

Cookie和session是配套使用的。Cookie是将一些文本信息以键值对的形式保存在客户端，而Session是将某些信息保存在服务器端。因为HTTP协议是无状态，Cookie是在客户端实现状态保持，Session是在服务器端实现状态保持，通过两者的结合实现客户端和服务器连接的状态保持。

那么如何才能将Cookie对应到正确的Session呢？利用sessionid。

通常在数据库中有一个seesion表，存放着所有的Session数据，大家都知道数据库数据都有一个id，而sessionid就对应的这个id，所以通过浏览器传递过来的Cookie，服务器能找到对应id的Session实现连接的状态保持。

例子来自 Session机制详解

让我们用几个例子来描述一下cookie和session机制之间的区别与联系。笔者曾经常去的一家咖啡店有喝5杯咖啡免费赠一杯咖啡的优惠，然而一次性消费5杯咖啡的机会微乎其微，这时就需要某种方式来纪录某位顾客的消费数量。想象一下其实也无外乎下面的几种方案：

1、该店的店员很厉害，能记住每位顾客的消费数量，只要顾客一走进咖啡店，店员就知道该怎么对待了。这种做法就是协议本身支持状态。

2、发给顾客一张卡片，上面记录着消费的数量，一般还有个有效期限。每次消费时，如果顾客出示这张卡片，则此次消费就会与以前或以后的消费相联系起来。这种做法就是在客户端保持状态。

3、发给顾客一张会员卡，除了卡号之外什么信息也不纪录，每次消费时，如果顾客出示该卡片，则店员在店里的纪录本上找到这个卡号对应的纪录添加一些消费信息。这种做法就是在服务器端保持状态。

5. 什么是token？有什么用？它有什么特点？为什么能防止CSRF？

原文 基于Token的身份验证的原理

token其实就是一个令牌，用于用户验证的，token的诞生离不开CSRF。正是由于上面的Cookie/Session的状态保持方式会出现CSRF，所以才有了token。

token的特点：

1. 无状态、可扩展
2. 支持移动设备
3. 跨程序调用
4. 安全

token的机制：

基于Token的身份验证的过程如下:

1. 用户登录校验，校验成功后就返回Token给客户端
2. 客户端收到token后保存在客户端，token可以保存在Cookies 或 Local Storage 或 Session Storage中。
3. 客户端每次访问API是携带Token到服务器端
4. 服务器端采用filter过滤器校验。验证传递的token和算法生成的token是否一致，校验成功则返回请求数据，校验失败则返回错误码

当我们在程序中认证了信息并取得 token 之后，我们便能通过这个 token 做许多的事情。我们甚至能创建一个基于权限的token传给第三方应用程序，这些第三方程序能够获取到我们的数据（当然只限于该 token 被允许访问的数据）。

图片来自 基于Token的身份验证的原理

一直困扰的一个问题就是，为什么恶意网站不能利用用户浏览器中的token，而能利用Cookie呢？

这是因为，在信任网站的HTML或js中，会向服务器传递参数token，不是通过Cookie传递的，若恶意网站要伪造用户的请求，也必须伪造这个token，否则用户身份验证不通过。但是，同源策略限制了恶意网站不能拿到信任网站的Cookie内容，只能使用，所以就算是token是存放在Cookie中的，恶意网站也无法提取出Cookie中的token数据进行伪造。也就无法传递正确的token给服务器，进而无法成功伪装成用户了。

6. 总结

现在明白CSRF、Cookie、Session和token了吗？

tom在村口tony师傅开的理发店那里办了一张理发卡(Cookie)，jerry从tom那里盗取了这张理发卡之后(CSRF)，去到理发店，tony师傅在洗剪吹理发系统中(session)验证发现是自己的理发卡，那么jerry就能在tony师傅这儿剪发了。

后来，为了防止这种行为，tony师傅为理发卡增加了密码(token)，就算jerry从tom那里盗取了理发卡(CSRF)，但是jerry不知道理发卡的密码(token)，那么jerry去到理发店之后，tony师傅在洗剪吹理发系统中发现是本店的理发卡之后，还会要求jerry给出密码(token)，这样就阻止了jerry的这种行为(CSRF)。

恶意网站的js中有一些构造出来的信任网站的URL，当用户触发了这个js之后，这个用户就请求了该URL了，然后就会根据这个URL进行操作，例如修改账户里的钱，或者删除掉某些数据等，总之这是一种很不安全的行为。所以，在信任网站的js中额外传递了一个参数token（通常是根据Cookie来生成的）给后端，这个参数只有在该信任网站的页面中才能生成对应的token，而恶意网站通过构造信任网站的URL能够伪造用户的操作，但是由于

同源策略

的原因，恶意网站无法使用Cookie也就无法生成对应的token，无法逃避信任服务器的验证。

7. 参考文献

[1] 安全|常见的Web攻击手段之CSRF攻击

[2] 彻底理解cookie，session，token

[3] 关于CSRF 和 csrftoken

[4] CSRF Token 的设计是否有其必要性？

[5] 为什么CSRF Token写在COOKIE里面

[6] CSRF攻击与防御（写得非常好）

[7] 什么是CSRF？可能多数人都不清楚，没事，一起来了解！！！

[8] 深入理解Cookie

[9] Session机制详解

[10] token验证机制

[11] 基于Token的身份验证的原理