一、CSRF原理
1、概念
用网站对用户网页浏览器的信任，挟持用户当前已登陆的Web应用程序，去执行并非用户本意的操作
2、受害者的两个操作
要完成一次CSRF攻击，受害者必须依次完成两个：
- 登录受信任网站A，并在本地生成Cookie。
- 在不登出A的情况下，访问危险网站B。 两者缺一不可
3、攻击三个部分
漏洞风险存在
- 需要目标站点或系统存在一个可以进行数据修改或者新增操作，且此操作被提交到后台的过程中，其未提供任何身份识别或校验的参数。后台只要收到请求，就立即下发数据修改或新增的操作
- 常见场景：用户密码的修改、购物地址的修改或后台管理账户的新增等等操作过程中
伪装数据操作请求的恶意链接或者页面
- CSRF漏洞风险存在了，如果需要真正的被利用，还需要对"修改或新增"数据操作请求的伪装，此时恶意攻击者只要将伪装好的"数据修改或新增"的请求发送给被攻击者，或者通过社工的方式诱使被攻击者在其cookie还生效的情况下点击了此请求链接，即可触发CSRF漏洞，成功修改或新增当前用户的数据信息。
诱使用户主动访问或登录恶意链接，触发非法操作
- 当前用户在不知情的情况下，访问了黑客恶意构造的页面或在链接，即在非本意的情况下完成黑客想完成的"非法操作"，实现了对当前用户个人信息的恶意操作。
二、CSRF的类型
get类型
get类型的CSRF是CSRF中最常见，危害最大，但也是最简单的一种类型了，只要一个http请求就可以了，这种类型的CSRF一般是由于程序员安全意识不强造成的。GET类型的CSRF利用非常简单，只需要一个HTTP请求，从地址栏我们可以明确看到修改密码时向服务器传递的参数列表
post类型
post是希望服务器做某项写操作，不幂等的。因为是设计成有影响的操作，所以它不能被缓存。 post请求一般都是表单提交，可以在body里面携带数据。
三、CSRF靶场练习（DVWA）
1、CRSF-low
step1：查看源码
发现只对 <math xmlns="http://www.w3.org/1998/Math/MathML"> p a s s n e w 和 pass_new和 </math>passnew和pass_conf进行了判断
step2：创建html文件
创建html文件，对应网址与修改密码的网址相同 使得用户在触发标签后，跳转到修改密码的界面，这个时候已经按照我们设定的密码进行了修改
step3：点击恶意链接后验证
输入之前修改的密码显示错误
输入正确的密码后，成功登录
2、CRSF-medium
step1：查看源码
查看源码可以发现，相较于low级，medium级对referer进行了判断
step2：burp抓包
而如果用户点击了攻击者的恶意地址，所提交的数据包的 Referer 字段与正常修改密码的字段内容不一样，因此会被服务器拦截，导致修改密码失败
step3：针对referer有以下解决方案
方法一、在恶意文件 中设置好正确的 Referer 字段
原本没有referer字段，在后面添加，然后放包
方法二、绕过referer
将其复制到以IP地址为名的html文件中
在浏览器中打开 注意打开时域名为http://127.0.0.1/html文件名
step3：点击恶意链接后验证
使用原来的密码无法登录，使用恶意代码中的代码就可以登录
3、CRSF-high
step1：查看源码
- 查看源码后发现，在之前的情况下增加了token的验证
- Token 是在服务端产生的。如果前端使用用户名/密码向服务端请求认证，服务端认证成功，那么在服务端会返回 Token 给前端。前端可以在每次请求的时候带上 Token 证明自己的合法地位。
step2：使用burp抓包
step3：进行暴力破解
step4：验证
使用原来的密码无法登录，使用恶意代码中的代码就可以登录
四、CSRF防御
1、 尽量使用POST，限制GET
GET接口太容易被拿来做CSRF攻击，接口最好限制为POST使用，GET则无效，降低攻击风险。
2、加验证码（二次确认）
验证码，强制用户必须与应用进行交互，才能完成最终请求。在通常情况下，验证码能很好遏制CSRF攻击。但是出于用户体验考虑，网站不能给所有的操作都加上验证码。因此验证码只能作为一种辅助手段，不能作为主要解决方案。
3、Referer Check（请求来源检查）
检查HTTP请求头部的Referer字段，该字段标明请求来源URL。直接在浏览器的地址栏中输入一个资源的URL地址，那么这种请求是不会包含 Referer 字段的，因为这是一个"凭空产生"的http请求，并不是从一个地方链接过去的。