CSRF攻击和防御（写的超详细）

当小绿登录正常网站服务器（VULNERABLE WEBSERVER)，进行某些操作，操作完成之后没有退出，继续访问了另一个存在病毒的网站（MALUCIOUS WEBSUITE)；

网站的WEB服务器验证不够，存在CSRF漏洞。

例如： 当前网站的验证方式只是验证的用户的session存在，那么他就是一个已经登录的状态，但是没有办法保证某一次请求就是当前用户触发的。
在现在的一些app或者是网页中，在交易时会输入一个短信验证码，但是有一些网站并不是属于金额交易的，所以就并没有做这些设置，那如何阻止这种的CSRF漏洞呢。

解决方法在网站服务器的服务端进行处理：

1. 尽量使用POST请求
get请求太容易被利用，攻击者可以构造一个img标签，通过图片资源嵌入恶意操作，而img又不能被过滤掉。所以接口最好限制为POST请求
2.加入验证码
POST请求也不是绝对安全的，攻击者可以通过内嵌框架，构建隐藏表单，当我们访问这个网站时候，就自动将这个表单提交了，从而造成了一次CSRF的攻击。所以这时候我们可以采用加入验证码的方式，因为攻击者所构造出来的就是伪的请求，所以在某一次提交时候，让用户提交验证码，或者滑块验证，能够确保这是一次用户的行为，而非黑客行为。
3.验证Referer
http头存在一个字段Referer，它能够记录当前一次请求的来源地址。什么意思呢，当我们访问正常网站时候，调用了某个接口例如192.108.12.88/transferxxxxx ------>而攻击者构造的伪请求地址113.132.44.53/gg.html 由于攻击者对正常网站实施CSRF攻击他只能在自己的站点里面进行构造请求，所以当Referer传过来是跟当前网站不同的域名，经过后端判断，如果Referer的值不是当前的网页就拒绝此次请求。
4.Anti CSRF Token
CSRF攻击之所以能够成功，主要是因为黑客能够完全伪造用户的请求，在这次请求中，用户的信息是存在cookie中的，所以黑客可以在不知道这些验证信息的情况下直接利用用户的cookie去跳过安全认证，我们要防御CSRF关键在于请求放入的时候黑客不能去伪造信息，并且这个信息不存在cookie之中，所以我们就可以在通过http的请求中或者是头信息中加入一个随机产生的token，这个token就会存在服务端，通过拦截器去验证这个token，如果请求头中不存在token或者token不正确，拦截器就会认为这是一次CSRF攻击，拒绝此次请求。
5.加入自定义head
跟第四中方法类似，但是这种方法是在header里进行传输的，自定义的header也可以产生随机的token
总结：

• 一般token放在head区域，或者from表单中。放在head区域中，使用js调取比较方便。

• 每次刷新网页，token也会随之刷新。服务端生成的token的值之后，存放在session中或者放在redis缓存中。使用完销毁。

• CSRF这种攻击方式，是黑客利用了我们登录的状态，在我们已经登录的网站里面错做一些隐私的或者敏感的功能；大部分人会选择第二中方式去防御CSRF攻击，在防御时，一定要确保token的保密性和随机性。