1. 什么是CSRF攻击/h1>

CSRF（Cross Site Request Forgery），中文是跨站点请求伪造。CSRF攻击者在用户已经登录目标网站之后，诱使用户访问一个攻击页面，利用目标网站对用户的信任，以用户身份在攻击页面对目标网站发起伪造用户操作的请求，达到攻击目的。

CSRF(Cross-Site Request Forgery)，跟XSS漏洞攻击一样，存在巨大的危害性。

你可以这么来理解：攻击者盗用了你的身份，以你的名义发送恶意请求，对服务器来说这个请求是完全合法的，但是却完成了攻击者所期望的一个操作，比如以你的名义发送邮件、发消息，盗取你的账号，添加系统管理员，甚至于购买商品、虚拟货币转账等。

两个条件：

1. C 用户访问站点 A 并产生了 cookie
2. 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保护的nbsp;

为什么有些框架（比如Spring Security)里防护CSRF的filter限定的Method是POST/PUT/DELETE等，而没有限定GET Method/p>

我们要保护的对象是那些可以直接产生数据改变的服务，而对于读取数据的服务，则不需要进行 CSRF 的保护。通常而言GET请作为请求数据，不作为修改数据，所以这些框架没有拦截Get等方式请求。比如银行系统中转账的请求会直接改变账户的金额，会遭到 CSRF 攻击，需要保护。而查询余额是对金额的读取操作，不会改变数据，CSRF 攻击无法解析服务器返回的结果，无需保护

5. 为什么对请求做了CSRF拦截，但还是会报CRSF漏洞/h1>

为什么我在前端已经采用POST+CSRF Token请求，后端也对POST请求做了CSRF Filter，但是渗透测试中还有CSRF漏洞/p>

直接看下面代码。

PS：这一点是很容易被忽视的，在笔者经历过的几个项目的渗透测试中，多次出现

可见，CSRF 是一种危害非常大的攻击，又很难以防范。目前几种防御策略虽然可以很大程度上抵御 CSRF 的攻击，但并没有一种完美的解决方案。一些新的方案正在研究之中，比如对于每次请求都使用不同的动态口令，把 Referer 和 token 方案结合起来，甚至尝试修改 HTTP 规范，但是这些新的方案尚不成熟，要正式投入使用并被业界广为接受还需时日。在这之前，我们只有充分重视 CSRF，根据系统的实际情况选择最合适的策略，这样才能把 CSRF 的危害降到最低。

参考文：Web安全之CSRF攻击 – 海角在眼前 – 博客园 (cnblogs.com)

来源：全栈开发与测试