参考：https://tech.meituan.com/2018/10/11/fe-security-csrf.html

一、CSRF（跨站伪造请求）

首先，CSRF是攻击者对浏览器的欺骗。

攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获得注册凭证（cookie），绕过后台用户验证，达到冒充用户对被攻击网站执行某项操作的目的。

流程：

受害者登录A网站(a.com)，保留了登录凭证Cookie
攻击者诱导受害者访问b.com
b.com向a.com发请求：a.com/act=xx。浏览器会以为是用户发请求，就默认携带a.com的Cookie
a.com接收到请求后，对请求进行验证，并确认是受害者的凭证，误以为是受害者自己发送的请求。
a.com以受害者的名义执行了act=xx。
6.攻击完成，攻击者在受害者不知情的情况下，冒充受害者，让a.com执行了自己定义的操作。

栗子：

一、GET类型的CSRF

假如博客园有个加关注的GET接口，blogUserGuid参数很明显是关注人Id，如下：

然后我只用在我的博客里加一个img标签

就有人会打开博客，自动加关注。

二、POST类型的CSRF

假如还是有个加关注的接口，不过已经限制了只获取POST请求的数据。这个时候就做一个第三方的页面，诱惑用户去打开，打开过的用户就中招了。

最好要加一层iframe，因为不加iframe页面会重定向，降低攻击的隐蔽性。弄一个表单，用户已打开，就自动提交。

特点：

攻击一般发起在第三方网站，而不是被攻击的网站。被攻击的网站无法防止攻击发生。
攻击利用受害者在被攻击网站的登录凭证，冒充受害者提交操作；而不是直接窃取数据。
整个过程攻击者并不能获取到受害者的登录凭证，仅仅是“冒用”。
跨站请求可以用各种方式：图片URL、超链接、CORS、Form提交等等。部分请求方式可以直接嵌入在第三方论坛、文章中，难以进行追踪。

CSRF通常是跨域的，因为外域通常更容易被攻击者掌控。但是如果本域下有容易被利用的功能，比如可以发图和链接的论坛和评论区，攻击可以直接在本域下进行，而且这种攻击更加危险。

防护策略：

一般CSRF由第三方网站发起，你无法防止被攻击，只能增强自己网站的防御能力来提升安全性。
CSRF有两个特点：

通常发生在第三方域名
CSRF攻击者只是使用Cookie，但是不能获取Cookie

针对这两点，有如下防御措施：

1. 同源检测

检查请求头的referer和origin。
对于origin，可直接确定域名，不含有query和path。
但是，有些情况，origin不存在，如IE11的cors请求，，302重定向。（因为重定向都是都是请求新的服务器的url，浏览器不想把此服务器的源泄露给新的服务器。）
对于referer，referer是浏览器挂上的，但是referer可以通过手动设置referer policy给隐藏掉，攻击者可以发不带referer字段的请求。
因此，拦截没有origin和referer的请求，十分重要。
但是对于在本域的csrf，这种检测是防御不了的。

2. CSRF token

这个是基于攻击者无法获取用户的信息（cookie、header和网页）。csrf之所以成功是因为服务器识别不出来到底是攻击者网站发的请求还是用户发的。
因此我们要求用户请求都携带一个csrf无法获取到的token。
在用户打开页面的时候，服务器给用户生成一个随机字符串+日期的token，token也放在服务器的session中，之后再加载页面，用js遍历dom树，给所有的form和a标签加token。
对于get请求，token加载query里，对于post，如表单，token加载value里。
这个方法在没有泄露token的话是十分安全的，但是对于所有的页面及里面的表单进行token验证，不能有一种通用的拦截方式来统一拦截，对于后台来讲，拦截检查工作量大。

3. 双重Cookie

1.1. 在用户访问网站页面时，向请求域名注入一个Cookie，内容为随机字符串
2.2 在前端向后端发起请求时，取出Cookie，并添加到URL的参数中
3.3 后端接口验证Cookie中的字段与URL参数中的字段是否一致，不一致则拒绝

优点：
1.无需使用Session，适用面更广，易于实施。
2.Token储存于客户端中，不会给服务器带来压力。
3.相对于Token，实施成本更低，可以在前后端统一拦截校验，而不需要一个个接口和页面添加。

缺点：
1.如果有其他漏洞（例如XSS），攻击者可以注入Cookie，那么该防御方式失效。
2.难以做到子域名的隔离。

4. samesite Cookie

Set-Cookie响应头中新增的属性，由strict 和lax 模式，strick模式下的cookie，若由第三方网站请求，请求中不会含有这个cookie字段。lax相反，为第三方cookie。

栗子：假如淘宝网站用来识别用户登录与否的 Cookie 被设置成了 Samesite=Strict，那么用户从百度搜索页面甚至天猫页面的链接点击进入淘宝后，淘宝都不会是登录状态，因为淘宝的服务器不会接受到那个 Cookie，其它网站发起的对淘宝的任意请求都不会带上那个 Cookie。

二、XSS（跨网站脚本攻击）

攻击者通过在目标网站上注入恶意脚本，使之在用户的浏览器上运行。利用这些恶意脚本，攻击者可获取用户的敏感信息如 Cookie、SessionID 等，进而危害数据安全。
恶意代码未经过滤，与网站正常的代码混在一起；浏览器无法分辨哪些脚本是可信的，导致恶意脚本被执行。
在部分情况下，由于输入的限制，注入的恶意脚本比较短。但可以通过引入外部的脚本（重定向），并由浏览器执行，来完成比较复杂的攻击策略。

防御：

XSS攻击有两要素

攻击者提交恶意代码
浏览器无法识别恶意代码，就执行恶意代码。

CSRF和XSS