【安全】CSRF

后面会把前端进阶的课程内容都总结一遍。有些都是很常见的知识，但是为了梳理自己的知识树，所以尽量模糊的地方都会记录

笔记列表在公众号右下角

今天需要记录的是另一大安全知识点 CSRF，是一个非常常见的安全问题

对于我们前端来说，也是必须要掌握的，因为面试会问啊~

好吧，今天需要记录的下面几块内容

1、CSRF 简介

2、CSRF 攻击原理

3、CSRF 防御措施

CSRF 简介

英文全称，Cross Site Request Forgery

中文翻译，跨站请求伪造

按照翻译，已经能理解他做什么事情了

1、跨站。在另一个网站上进行攻击操作

2、请求伪造。假冒用户操作，携带用户信息，伪造请求

CSRF 和 XSS

CSRF 个人感觉一定程度上感觉属于 XSS

CSRF 攻击载体是 请求，XSS攻击 载体是 恶意脚本，CSRF 能做的，XSS 都能做。

所以我感觉 CSRF 属于 XSS，但是他们攻击载体不一样，而且显然CSRF 比 XSS 成本更低，并且难以防范

所以我想这就是他们作为两种安全漏洞存在的原因之一把

CSRF 攻击原理

攻击重点就是，劫持用户的 Cookie

怎么劫持的呢？？

下面我们先说个场景

比如现在你有个贴吧账户其中发帖的接口是 http://a.com/addPost

参数 content 是 帖子的内容

如果你发帖内容是 xxx，就会这么请求，http://a.com/addPost?content=xxx

但是这个接口需要携带登录后的 cookie 才能调通，所以你肯定是需要登录的

下面开始攻击步骤

1、你登录了贴吧，服务端返回 cookie，保存在浏览器端

2、有人给你发了一个网站链接 b.com，在这个网站中，调用了发帖接口，内容是 xxxx

3、你手贱，点开了链接，因为你没有退出登录 a.com，b.com 中 就会携带你的 cookie 调用 发帖接口

4、a.com 服务端收到 带有 cookie 的发帖请求，认为是你发送的，那么帖子发送成功，攻击也就成功了

看了上面的步骤，其实还是有一个问题

在 b.com 调用 a.com 的接口，怎么会携带上 a.com 的 cookie？cookie 不是不能跨域访问吗？

没错，的确不能跨域访问，如果你直接在 b.com 中 使用 ajax 请求接口，的确不会携带上 cookie，如下

但是一样有方法，就是利用 script ，img，iframe 等不受同源策略影响的标签对 接口进行请求

比如上面的发帖接口，只要你在 b.com 中加入 img 标签，如下

<img  src="http://a.com/addPost?content=xxx" />

那么这个img 发起的请求，就会把你的 cookie 给带走

也许你又会问，img 那些只能发 get 请求啊，那 post 请求怎么办？

不用怕，一样可以！！答案就是！！

在 b.com 的页面中，建立表单提交！

然后控制他自动提交就可以了

CSRF 防御措施

上面我们已经讲了攻击的原理了，我们可以绕过同源策略，携带用户cookie伪造请求，冒充用户操作

所以我们必须想出办法来杜绝 CSRF ，不然整天被人假冒

既然是防御，我们就要从他是攻击的特点开始入手

1、跨站

2、利用 cookie 伪造请求

3、隐性请求，用户不知情

针对 CSRF 攻击的 三大特点来逐个击破

1防止跨站

既然他是在别的站点进行请求的发送，那么我只要识别这个请求的来源不就行了？

没错，我们可以获取到请求从哪个网站发起的

怎么获取？

答案就在 请求的 请求头中，有一个 referer 字段，记录了 HTTP 请求的来源地址

所以我们只要拿到 请求头的 referer 信息，验证是否是从我站发起请求，然后才决定是否响应操作

当然这个验证是由服务端完成的，前端只能看戏

比如你从 b.com 发起 a.com/addPost 的 请求，那么请求的 referer 就是 b.com

如果服务端判断 你的 referer 不是 a.com ，那你特么肯定是想攻击我的用户啊，不答应！

告诉黑客

但是这种方法其实还是不太安全，因为黑客甚至可以篡改 Referer 的值。

并且有些用户为了隐私，会设置浏览器不发送 Referer 字段，这样的话，正常操作也会被当成 CSRF 了

所以这种方法没有得到推广

2防止利用cookie伪造请求

CSRF 得逞的原因是什么！？？

没错，就是利用 cookie 会随着请求一起发送的基础上，假冒我们去进行操作

所以，我们不用 cookie 不就行了？？

cookie 是用来验证登录的，如果不用 cookie 用什么呢？

那就是！我们自己用算法生成一个 token

当用户登录的时候，就给他返回一个 token，然后用户的任何操作都需要带上 token 这个参数

比如登录之后我们的token 是 xxxx，然后我们发帖就会这么发送

http://a.com/addPost? content=xxx & token = xxxx

这个方法是现在最主流最有效的防御 CSRF的方法，因为我们的 token 算法是不公开的，所以

黑客无法计算出 token，并且跨站请求也无法自动携带 token

所以任何跨站的操作都不攻自破

3防止用户不知情

黑客利用跨站请求 假冒用户，一切都是在用户不知情的情况下的

用户不知情下发帖，用户不知情下转账，然后才会默认了请求的发生

那我们让用户知情不就行了？

比如在发帖的时候，需要输入验证码来确认操作

只有验证码正确了，才响应操作。而 CSRF 是无法知道验证码是什么，所以跨站的请求是肯定不会成功了

但是如果任何操作都需要验证码，用户体验也是非常糟糕而来，所以通常我们只会在重要的操作下才会需要输入验证码

比如涉及到金钱，用户安全等等的操作

总结

利用 CSRF 攻击的特点，我们得出了三种防御方式

1、防止跨站，就是 Referer 验证

2、防止利用 Cookie 伪造请求，就是 Token 验证

3、防止用户不知情，就是 验证码验证

所以我们有三种防御的方法，但是在实际情况下我们的防御通常不可能只选择某一种，而是多种方法一起使用，层层保护

比如服务端在处理请求的时候

1、先判断 referer 来过滤一些低级的 CSRF 攻击

2、然后使用 token 来重点防御 CSRF

3、接着在重要的操作下，使用验证码验证用户

最后

鉴于本人能力有限，难免会有疏漏错误的地方，请大家多多包涵， 如果有任何描述不当的地方，欢迎后台联系本人。