什么是CSRF（简单易懂，有逻辑）

1. CSRF漏洞

CSRF（Cross-site request forgery）跨站请求伪造，也被称为One Click Attack 或者Session Riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与XSS非常 不同，XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击性往往不大流行（因此对其进行防范的资源也相对少）和难以防范，所以被认为比XSS更具危险性。

2. 漏洞简介

跨站请求攻击，简单地说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并执行一些操作（如发邮件、发消息、甚至财产操作：转账、购买商品等）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去执行。这利用了web中用户身份认证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。

3. CSRF的成因

CSRF漏洞的成因就是网站的cookie在浏览器中不会过期，只要不关闭浏览器或者退出登录，那以后只要是访问这个都网站，会默认你已经登录的状态。而在这个期间，攻击者发送了构造好的CSRF脚本或包含CSRF脚本的链接，可能会执行一些用户不想做的功能（比如是添加账号、ajax异步传输【通过JS去发送请求，然后获取信息】。与钓鱼网站不同，钓鱼网站需要输入账号和密码，而CSRF只需要访问链接或者网页即可。

4. CSRF分类

4.1 GET型：

如果一个网站某个地方的功能，比如用户修改邮箱是通过GET请求进行修改的。如：/user.php?id=1&email=123@163.com ，这个链接的意思是用户id=1将邮箱修改为123@163.com。当我们把这个链接修改为 /user.php?id=1&email=abc@163.com ，然后通过各种手段发送给被攻击者，诱使被攻击者点击我们的链接，当用户刚好在访问这个网站，他同时又点击了这个链接，那么悲剧发生了。这个用户的邮箱被修改为 abc@163.com 了

4.2 POST 型：

在普通用户的眼中，点击网页->打开试看视频->购买视频是一个很正常的一个流程。可是在攻击者的眼中可以算正常，但又不正常的，当然不正常的情况下，是在开发者安全意识不足所造成的。攻击者在购买处抓到购买时候网站处理购买(扣除)用户余额的地址。比如：/coures/user/handler/25332/buy.php 。通过提交表单，buy.php处理购买的信息，这里的25532为视频ID。那么攻击者现在构造一个链接，链接中包含以下内容

<form action=/coures/user/handler/25332/buy method=POST>
<input type="text" name="xx" value="xx" />
</form>
<script> document.forms[0].submit(); </script> 

当用户访问该页面后，表单会自动提交，相当于模拟用户完成了一次POST操作，自动购买了id为25332的视频，从而导致受害者余额扣除

5. CSRF与XSS漏洞区别

**CSRF：**利用网站对用户网页浏览器的信任（没有盗用用户的cookie，直接利用浏览器存储的coolie让用户去执行某个操作。）
**XSS：**利用用户对指定网站的信任

6. CSRF漏洞检测

1. 检测CSRF漏洞是一项比较繁琐的工作，最简单的方法就是抓取一个正常请求的数据包，去掉Referer字段后再重新提交，如果该提交还有效，那么基本上可以确定存在CSRF漏洞。
2. 随着对CSRF漏洞研究的不断深入，不断涌现出一些专门针对CSRF漏洞检测的工具，若CSRFTester，CSRF Request Builder等。
   

7. CSRF的高危触发点

1. 论坛交流
2. 用户中心
3. 反馈留言
4. 交易管理
5. 后台管理
   

8. CSRF漏洞的危害

• 伪造HTTP请求进行未授权操作
• 篡改、盗取目标网站上的重要用户数据
• 未经允许执行对用户名誉或者资产有害的操作，比如：散播不良信息、进行消费等
• 如果通过使用社工等方式攻击网站管理员，会危害网站本身的安全性
• 作为其他攻击向量的辅助攻击手法，比如配合XSS
• 传播CSRF蠕虫
  

9. CSRF挖掘技巧

9.1漏洞产生的条件

1. 被害用户已经完成身份认证
2. 新请求的提交不需要重新身份认证或确认机制
3. 攻击者必须了解Web APP请求的参数构造
4. 诱使用户触发攻击的指令(社工)
   

9.2 漏洞产生的位置

密码修改处、点赞、转账、注销、删除等，有交互个数据传输的地方就可能有存在CSRF，但是注意，挖掘时最好通过判断有无二次验证（修改密码需要旧密码验证）或着通过有无token等来快速判断。、

10. CSRF防御措施

1. Referer验证

根据HTTP协议，在HTTP头中有一个字段叫Referer，它记录了该HTTP请求的来源地址。在通常情况下，访问一个安全受限页面的请求必须来自于同一个网站。比如某银行的转账是通过用户访问http://bank.test/test?page=10&userID=101&money=10000页面完成，用户必须先登录bank.test，然后通过点击页面上的按钮来触发转账事件。当用户提交请求时，该转账请求的Referer值就会是转账按钮所在页面的URL（本例中，通常是以bank. test域名开头的地址）。而如果攻击者要对银行网站实施CSRF攻击，他只能在自己的网站构造请求，当用户通过攻击者的网站发送请求到银行时，该请求的Referer是指向攻击者的网站。因此，要防御CSRF攻击，银行网站只需要对于每一个转账请求验证其Referer值，如果是以bank. test开头的域名，则说明该请求是来自银行网站自己的请求，是合法的。如果Referer是其他网站的话，就有可能是CSRF攻击，则拒绝该请求。

2. Token验证

CSRF攻击之所以能够成功，是因为攻击者可以伪造用户的请求，该请求中所有的用户验证信息都存在于Cookie中，因此攻击者可以在不知道这些验证信息的情况下直接利用用户自己的Cookie来通过安全验证。由此可知，抵御CSRF攻击的关键在于：在请求中放入攻击者所不能伪造的信息，并且该信息不存在于Cookie之中。鉴于此，系统开发者可以在HTTP请求中以参数的形式加入一个随机产生的token，并在服务器端建立一个拦截器来验证这个token，如果请求中没有token或者token内容不正确，则认为可能是CSRF攻击而拒绝该请求。

3. 增加验证码验证

Spring security的表单验证是通过过滤器链中的 UsernamePasswordAuthenticationFilter 来完成的，我们增加的验证码过滤器应该插在 UsernamePasswordAuthenticationFilter 之前，如果验证码校验不通过，直接返回，无需进行账户密码的校验。

11. CSRF漏洞防御总结

CSRF攻击的核心是伪造请求，识别这种的攻击的重点就是判断当前操作是否伪造；通过在当前页面生成随机Token，后端业务逻辑在处理操作时，应该先校验Token的有效性，然后才能处理业务流程。尤其在核心业务中，采用Token+Referer的组合进行操作验证；采用验证码校验操作是因为攻击者无法预知验证码的值，进而无法构造有效的攻击；但毫无疑问，验证码会一定程度地影响用户体验，所以我们要在安全和用户体验之间找到一个平衡点。