1.CSRF攻击是什么

csrf全名叫跨站请求伪造，也称为Sea Surf或者XSRF。Cross Site Request Forgery
攻击方式原理：利用CSRF诱骗用户代表攻击者自己执行登录。用户持有的权限级别决定了CSRF攻击的影响范围。这种攻击利用了一个web漏洞：一旦用户通过网站服务的身份认证，网站就完全信任，以你为用户的当前登录信息被存放在cookie中。
在网络安全领域，通常认为CSRF伪造攻击是一个沉睡的巨人[a sleeping giant]，已经证明只要合理地发起CSRF攻击，它就可以是一个隐蔽性很强又很有效的攻击，但是它并没有得到应有的重视。CSRF攻击很常见。多次出现在OWASP Top10列表。

OWASP: 开放式Web应用程序安全项目（OWASP，Open Web Application Security Project）是一个组织，它提供有关计算机和互联网应用程序的公正、实际、有成本效益的信息。其目的是协助个人、企业和机构来发现和使用可信赖软件。开放式Web应用程序安全项目（OWASP）是一个非营利组织，不附属于任何企业或财团。非国内组织，但是国内也在发展该类组织。

但是可以知道的是，攻击者利用漏洞发起的跨站脚本攻击XSS比任何跨站请求伪造CSRF对网站安全来说风险更高，因为CSRF攻击有一个很大的限制，那就是它只能引起状态的变更，却无法接收到HTTP响应的内容。

2.CSRF攻击如何实现

一般为两个步骤

诱骗用户点击某个链接或者加载某个页面，这一步一般通过社会工程学【猜测用户心理】和恶意链接实现。
从受害者的浏览器向网站服务器发送一个精心设计的看似合法的请求，该请求携带了攻击者设置的参数以及受害者在目标网站上的所有cookie。

所以攻击者在诱骗成功后是可以知道被骗用户可以在该网站执行那些行为。即使请求是被诱导发送的，但是携带了HTTP认证+cookie请求的都会被目标网站视为合法请求。

一般用户向一个网站发送请求的时候，会检查与该网站相关的所有cookie，然后将这些相关cookie一起发送给网站服务端，所以所有发送到该网站的请求都会包含这些cookie。而通常cookie值包含用户的认证信息，并且代表了用户和服务端的会话。本身是用于服务用户体验的，也就是cookie的本地保存可以让用户不必每次访问网页时都进行身份验证。但是这也给CSRF攻击一个契机去获取合法cookie伪造requet请求然后携带自己设计的参数，可能包含一些脚本包括js注入或者其他什么的。

跨站请求伪造攻击仅在受害者已经通过身份验证的情况下进行，因为这样可以直接绕过身份验证，但也正是如此，CSRF也只能通过受害用户拥有的权限去进行攻击，用户无法访问的资源内容CSRF也没有办法去攻击，也就是这些用户没有权限访问的资源在CSRF攻击下是安全可靠的。

在这里插入图片描述

2.1 使用GET请求的CSRF的攻击例子

HTTP的get请求本质上是一种幂等的访问方法，这说明开发web的时候get请求不应该用于修改数据库状态，而只作为一个请求访问或者链接跳转，通俗地讲，发送一个GET请求不应该引起任何数据状态的改变。用于修改状态更加合适的是post方法，特别是对用户信息状态改变的情况。【登录注册都应用post请求】

HTTP/1.1中对幂等性的定义是：一次和多次请求某一个资源对于资源本身应该具有同样的结果（网络超时等问题除外）。也就是说，其任意多次执行对资源本身所产生的影响均与一次执行的影响相同。

简单来说，业务开发中，经常会遇到重复提交的情况，无论是由于网络问题无法收到请求结果而重新发起请求，或是前端的操作抖动而造成重复提交情况，最后应该与只提交一次的所造成的效果和影响相同。

当用户点击攻击者提供的恶意链接后，该恶意网站就会执行一个脚本，引起用户的浏览器发起一个未经受害者统一的请求，受害者用户也不会意识到，在服务端看来该请求就是用户发送的，因为其中包含了验证用户身份的cookie。下面展示通过get请求进行CSRF攻击。

背景：一个有漏洞的服务器希望获得一个get请求去进行转账业务实现。【举例而已】

攻击者在自己的恶意网站中输入一个合法的get请求链接，并包装在img标签内。注意攻击者并不能直接访问这个链接，因为攻击者不是example网站的用户，没有进行过身份验证，直接访问一定是失败的。所以现在是要让受害者用户去帮攻击者访问，如果是受害者用户访问这个链接，那么因为受害者用户浏览器的cookie里带有用户的验证信息，并且发送请求的时候会自动携带cookie。

解释这里为什么用data-fr-src，使用data-src也可以，data-xxx是一种自定义标签，符合H5规范，在img标签中表示懒加载，也就是当有人访问的时候才会自动把data-src中的链接交给src访问。

<img src="" data-fr-src="http://example.com/transfer?amount=1000000&account=Fred" />

诱骗用户进入自己的恶意网站，访问到这个img标签就相当于用受害者的浏览器携带用户的验证信息去发送该请求。而服务端正是要get请求+用户验证信息，这些条件都满足了，服务端开始转账服务。
因为这次跨站伪造的请求中携带攻击者设计好的参数，并且通过受害者用户的浏览器去发送，在服务端看来属于合法请求，受害者用户账户里的100w被转账给了Fred【名称】攻击者。

2.2 使用post请求的CSRF攻击

一般程序都更愿意使用post请求去改变数据库状态而不用幂等的get请求。post请求的参数在请求体中，因此诱骗受害者发送post请求会更难一些，诱骗受害者发送get请求只需要让用户访问带参的URL即可。使用post请求的时候需要将请求体参数附加到请求中，这就需要在恶意网站中加载有js脚本，当用户访问的时候就触发js脚本，js脚本就会发送一个带有设计好的请求体的请求。

下面展示js脚本：

<!--这里表示知道已访问恶意网站，就会自动加载命令"document.csrf.submit()"，表示将文档中名为csrf的表单进行submit提交-->
<body onload="document.csrf.submit()"><!--发送表单，表单内的元素是已经被我们赋值了的，作为请求体--><form action="http://example.com/transfer" method="POST" name="csrf"><input type="hidden" name="amount" value="1000000" /><input type="hidden" name="account" value="Fred" /></form>
</body>

只要恶意网页一加载，就会触发body中的onload事件，运行document.csrf.submit()命令，表示将文档中名为csrf的表单进行submit提交操作。而且input表单框是被隐藏的。

剩下的就和get请求的CSRF攻击一样了，诱骗用户进入恶意网站，网站借用户浏览器发送post请求，服务端认可该post请求，用户丢失100w。

3.如何防御CSRF攻击

安全专家提出许多防御CSRF攻击的机制，比如使用referer请求头、使用HttpOnly标志、使用jQuery发送X-Requested-With自定义请求头等等。但是这些方法并非适用于所有场景。在某些情况下他们是低效率的。比较高效的实用的是CSRF令牌。

3.1 什么是CSRF令牌

最流行的CSRF防范是使用令牌机制，该令牌与指定的用户相关联，每次接受请求更改表单前服务端会将令牌值作为隐藏值发送给用户，而用户再根据这个即时得到的令牌放进post体里，而攻击者的恶意网站是不可能知道这个令牌的，因为攻击者没办法看到和获取到用户浏览器的响应体，也就是无论攻击者如何设计post请求的CSRF的请求参数，都无法被服务端认为是合法请求，因为不存在令牌匹配。