CSRF（Cross-site request forgery）跨站请求伪造。即攻击者利用用户登录的身份凭证，绕过后台的用户验证，进行一些不正当的操作！
几种常见类型的 CSRF
(1) GET 类型
通常是借助有 src 属性的标签
<img src="http://bank.example/withdraw?amount=10000&for=hacker" >
那么只要当受害者访问有该图片的 img 页面后，浏览器就会发送一个地址为bank.example/withdrawacc… 的请求。且该请求是由用户的登录凭证的，因为是在用户本地发送的请求。
(2) POST 类型
通常是借助自动提交的表单
<form action="http://bank.example/withdraw" method=POST>
<input type="hidden" name="account" value="xiaoming" />
<input type="hidden" name="amount" value="10000" />
<input type="hidden" name="for" value="hacker" />
</form>
<script> document.forms[0].submit(); </script>
那么用户访问了该页面后，表单就会自动提交，那就会触发一次地址为bank.example/withdraw 的 POST 请求。
(3) 链接类型
不同于以上两个用户只要访问页面就会触发，链接类型的需要用户手动去点击链接才会触发。
例如：攻击者在某个社交平台上发表一些带有恶意链接的评论，那么只要我们点击，那就中招了hh。
<a href="http://test.com/csrf/withdraw.php?amount=1000&for=hacker" taget="_blank"> 重磅消息！！ <a/>
CSRF的特点
-
攻击一般发起在第三方网站，而不是被攻击的网站。被攻击的网站无法防止攻击发生。
-
攻击者利用受害者在被攻击网站的登录凭证，冒充受害者提交操作；而不是直接窃取数据。 并没有拿到用户的 cookie
-
对于服务器返回的结果，如果浏览器有
同源限制，那攻击者也拿不到返回的数据。 -
所以相对于读取数据的服务，我们更要重点关注数据直接改变的服务，比如转账...
CSRF 预防
-
进行二次验证： 在进行一些例如转账的操作时，可以使用验证码、生物识别等进行二次验证
-
用户凭证定期失效： 即对于那些危险系数较高的系统，例如银行app等，我们可以把用户凭证的有效期设置尽可能短一些。
-
cookie 和 token
