1. 什么是CSRF攻击？
CSRF（Cross Site Request Forgery），中文是跨站点请求伪造。CSRF攻击者在用户已经登录目标网站之后，诱使用户访问一个攻击页面，利用目标网站对用户的信任，以用户身份在攻击页面对目标网站发起伪造用户操作的请求，达到攻击目的。
CSRF(Cross-Site Request Forgery)，跟XSS漏洞攻击一样，存在巨大的危害性。
你可以这么来理解：攻击者盗用了你的身份，以你的名义发送恶意请求，对服务器来说这个请求是完全合法的，但是却完成了攻击者所期望的一个操作，比如以你的名义发送邮件、发消息，盗取你的账号，添加系统管理员，甚至于购买商品、虚拟货币转账等。
两个条件：
- C 用户访问站点 A 并产生了 cookie
- C 用户没有退出 A 同时访问了 B
2. CSRF漏洞挖掘
- 抓取一个正常请求的数据包，如果没有Referer字段和token，那么极有可能存在CSRF漏洞
- 如果有Referer字段，但是去掉Referer字段后再重新提交，如果该提交还有效，那么基本上可以确定存在CSRF漏洞。
- 利用工具进行CSRF检测。如：CSRFTESTER，CSRF REQUEST BUILDER等
-
使用burpsuite快速生成CSRF poc,当我们发现一个页面存在CSRF漏洞后，可以通过burpsuite快速生成攻击代码
3. CSRF攻击的防御
- CSRF攻击的防御
- 在请求地址中添加 token 并验证(Anti-CSRF token)
- 在 HTTP 头中自定义属性并验证
- 主流的框架一般都包含了CSRF的拦截
4. 什么样的请求是要CSRF保护的?
为什么有些框架（比如Spring Security)里防护CSRF的filter限定的Method是POST/PUT/DELETE等，而没有限定GET Method?
我们要保护的对象是那些可以直接产生数据改变的服务，而对于读取数据的服务，则不需要进行 CSRF 的保护。通常而言GET请作为请求数据，不作为修改数据，所以这些框架没有拦截Get等方式请求。比如银行系统中转账的请求会直接改变账户的金额，会遭到 CSRF 攻击，需要保护。而查询余额是对金额的读取操作，不会改变数据，CSRF 攻击无法解析服务器返回的结果，无需保护
5. 为什么对请求做了CSRF拦截，但还是会报CRSF漏洞?
为什么我在前端已经采用POST+CSRF Token请求，后端也对POST请求做了CSRF Filter，但是渗透测试中还有CSRF漏洞?
直接看下面代码。
// 这里没有限制POST Method，导致用户可以不通过POST请求提交数据。
@RequestMapping("/url")
public ReponseData saveSomething(XXParam param){
// 数据保存操作...
}
PS：这一点是很容易被忽视的，在笔者经历过的几个项目的渗透测试中，多次出现
可见，CSRF 是一种危害非常大的攻击，又很难以防范。目前几种防御策略虽然可以很大程度上抵御 CSRF 的攻击，但并没有一种完美的解决方案。一些新的方案正在研究之中，比如对于每次请求都使用不同的动态口令，把 Referer 和 token 方案结合起来，甚至尝试修改 HTTP 规范，但是这些新的方案尚不成熟，要正式投入使用并被业界广为接受还需时日。在这之前，我们只有充分重视 CSRF，根据系统的实际情况选择最合适的策略，这样才能把 CSRF 的危害降到最低。
参考文：Web安全之CSRF攻击 - 海角在眼前 - 博客园 (cnblogs.com)
