Web后端：CSRF攻击及应对方法

CSRF攻击是开发Web后端时需要重点解决的问题。

那么什么是CSRF攻击呢？

CSRF跨站点请求伪造(Cross—Site Request Forgery)，其主要利用的是Cookie的一个弱点，就是Cookie 最初被设计成了允许在第三方网站发起的请求中携带：

关于Cookie :

HTTP 协议是无状态的，可以通过 Cookie 来维持客户端与服务端之间的“会话状态”。服务端通过 Set-Cookie 响应头设置 Cookie 到客户端，而客户端浏览器会自动在下次向服务器发送请求时添加名为 Cookie 的请求头，以携带服务端之前“埋下”的内容，从而使得服务端可以识别客户端的身份。

第三方Cookie：

由当前a.com 页面发起的请求的 URL 不一定也是 a.com 上的，可能有 b.com 的，也可能有 c.com 的。如果把发送给 a.com 上的请求叫做第一方请求（first-party request），发送给 b.com 和 c.com 等的请求叫做第三方请求（third-party request），第三方请求和第一方请求一样，都会带上各自域名下的 cookie，所以就有了第一方 cookie（first-party cookie）和第三方 cookie（third-party cookie）的区别。CSRF 攻击，就是利用了第三方 cookie 。

 CSRF发起攻击的过程为：

1. 用户C打开浏览器，访问受信任网站A，输入用户名和密码请求登录网站A；

2.在用户信息通过验证后，网站A产生cookie信息并返回给浏览器，此时用户登录网站A成功，可以正常发送请求到网站A；

3. 用户未退出网站A之前，在同一浏览器中，打开一个TAB页访问网站B；

4. 网站B接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点A；

5. 浏览器在接收到这些攻击性代码后，根据网站B的请求，在用户不知情的情况下携带第三方cookie信息，向网站A发出请求。网站A并不知道该请求其实是由B发起的，所以会根据用户C的cookie信息以C的权限处理该请求，导致来自网站B的恶意代码被执行。

那么如果应对CSRF攻击呢，主要有以下几种手段：

1. SameSite属性

Google 起草了一份草案来改进 HTTP 协议，就是为 Set-Cookie 响应头新增 SameSite 属性，它用来标明这个 cookie 是个“同站 cookie”，同站 cookie 只能作为第一方 cookie，不能作为第三方 cookie。SameSite 有两个属性值，分别是 Strict 和 Lax。

SameSite=Strict：

严格模式，表明这个 cookie 在任何情况下都不可能作为第三方 cookie，绝无例外。比如说假如 a.com 设置了如下 cookie：

Set-Cookie: foo=1; SameSite=Strict
Set-Cookie: bar=2

这时你在 b.com 下发起的对 a.com 的任意请求中，foo 这个 cookie 都不会被包含在 Cookie 请求头中，但 bar 会。举个实际的例子就是，假如淘宝网站用来识别用户登录与否的 cookie 被设置成了 SameSite=Strict，那么用户从百度搜索页面甚至天猫页面的链接点击进入淘宝后，淘宝都不会是登录状态，因为淘宝的服务器不会接受到那个 cookie，其它网站发起的对淘宝的任意请求都不会带上那个 cookie。

SameSite=Lax：

宽松模式，比 Strict 放宽了点限制：假如这个请求是改变了当前页面或者打开了新页面，且同时是个 GET 请求（因为从语义上说 GET 是读取操作，比 POST 更安全），则这个 cookie 可以作为第三方 cookie。比如说假如 a.com 设置了如下 cookie：

Set-Cookie: foo=1; SameSite=Strict
Set-Cookie: bar=2; SameSite=Lax
Set-Cookie: baz=3

当用户从 b.com 点击链接进入 a.com 时，foo 这个 cookie 不会被包含在 Cookie 请求头中，但 bar 和 baz 会，也就是说用户在不同网站之间通过链接跳转是不受影响了。但假如这个请求是从 b.com 发起的对 a.com 的异步请求（不会改变当前页面，也不会打开新页面），或者页面跳转是通过表单的 post 提交触发的，则 bar 也不会发送。

SameSite=None:

允许请求自动携带上 Cookie

2.通过请求头中的Referer 字段

根据 HTTP 协议，在 HTTP 头中有一个字段叫 Referer，浏览器会自动在其中设置该 HTTP 请求的来源地址，比如来源于a.com/xxx的请求，那么请求头中会包含

Referer: a.com/xxx 

因此后台程序只需检查HTTP请求头中的 Referer信息是不是就是本网站的URL即可。

3.通过XSRF-TOKEN

CSRF攻击之所以能产生，是因为当发起第三方请求时，浏览器会自动为请求添加Cookie，但实际上黑客是不知道Cooke的内容的，因此可以通过使用Token的方式来应对CSRF攻击，方法为：

1.后端程序定期的产生随机数，并把随机数以名字XSRF-TOKEN放入到Cookie中。

2.前端程序发送请求前，读取Cookie中的Token，然后将XSRF-TOKEN的内容放入到请求头的X-XSRF-TOKEN中（注Axios可以自动将Cookie中的XSRF-TOKEN放入到请求头的X-XSRF-TOKEN中）。

3后端程序接收道请求后，检查请求头中的X-XSRF-TOKEN是否为合法的Token。

这种应对方法的原理在于，攻击网站只能发起第三方请求，但是由于跨域原因，他是无法读取到Cookie的内容的，因此也就无法安置正确的X-XSRF-TOKEN，后端可以通过检查X-XSRF-TOKEN来判定这个请求是否为合法请求。