- 除了token方式的csrf防御外，还有cookie方式的双重Cookie验证
- 普通的token方式
- 用户登陆一个网站时，服务器会生成一个token，并将它存于session之中。
- 之后，每次页面加载时，对页面中所有的a和form标签后加入这个Token（隐藏的）（可以通过JS遍历整个DOM树，对于DOM中所有的a和form标签后加入Token或是手动在HTML标签后追加）
<input type="hidden" name="_token" value="{{ csrf_token() }}" />
- 用户提交表单后，后端会对表单中的csrf_token和session中的进行比对，相同则通过
- 在用户访问网站页面时，向请求域名注入一个Cookie，内容为随机字符串（例如csrfcookie=v8g9e4ksfhw）。同时向客户端的cookie中也设置csrfcookie=v8g9e4ksfhw
- 在前端向后端发起请求时，取出Cookie，并添加到URL的参数中（接上例POST https://www.a.com/comment?csrfcookie=v8g9e4ksfhw）。
- 后端接口验证Cookie中的字段与URL参数中的字段是否一致，不一致则拒绝。
简单来说除了cookie中的CSRF-Token外，请求体(POST)或者请求参数(GET)中也要有一个CSRF-Token。后端比较Cookie和请求体(POST)或者请求参数(GET)中的CSRF-Token是否一致，一致才执行请求。 因为CSRF攻击实际上是获取不到Cookie(CSRF一般通过钓鱼网站进行，而第三方网站是获取不到Cookie)的，而请求体(POST)或者请求参数(GET)中的CSRF-TOKEN需要中cookie中提取,这样就保证只有自己网站的页面能够在请求体或请求参数中设置CSRF-TOKEN。这样就完成了CSRF的防御。
- CSRF防御总结
CSRF的定义：攻击者跨站点借用用户COOKIE执行非用户本意的操作。
攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。
CSRF防御：因为这些攻击手段都是攻击者注入在第三方攻击网站中的，由于攻击者无法获知csrf_token的具体内容，所以也就无法在这些攻击手段中加入csrf_token来通过后台的验证。从而达到防御目的。
