CSRF即跨站请求攻击。简单的说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己以前认证过的站点并运行一些操作（如发邮件，发消息，甚至财产操作（如转账和购买商品））。因为浏览器之前认证过，所以被访问的站点会绝点是这是真正的用户操作而去运行。
这就利用了web中用户身份认证验证的一个漏洞：简单的身份验证仅仅能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。
其实可以这么理解CSRF攻击：攻击者盗用了你的身份，以你的名义发送恶意请求。CSRF能够做的事情包含：以你的名义发送邮件；发消息；盗取你的账号；甚至于购买商品、虚拟货币转账......造成的问题包含个人隐私泄露以及财产安全。
一、CSRF原理
从上图能够看出，要完毕一次CSRF攻击，受害者必须依次完毕两个步骤：
登录受信任站点A，并在本地生成Cookie。
在不登出A的情况下，訪问危急站点B。
二、常见的攻击类型
1.GET类型的CSRF
仅仅须要一个HTTP请求。就能够构造一次简单的CSRF。
样例：
银行站点A：它以GET请求来完毕银行转账的操作，如：http://www.mybank.com/Transfer.php?toBankId=11&money=1000
危急站点B：它里面有一段HTML的代码例如以下：
<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>
首先。你登录了银行站点A，然后訪问危急站点B，噢，这时你会发现你的银行账户少了1000块
为什么会这样呢？原因是银行站点A违反了HTTP规范，使用GET请求更新资源。
在訪问危急站点B的之前。你已经登录了银行站点A，而B中的 一个合法的请求，但这里被不法分子利用了）。所以你的浏览器会带上你的银行站点A的Cookie发出Get请求，去获取资源以GET的方式请求第三方资源（这里的第三方就是指银行站点了，原本这是http://www.mybank.com/Transfer.php?toBankId=11&money=1000 ，结果银行站点服务器收到请求后，觉得这是一个更新资源操作（转账操作），所以就立马进行转账操作。
2、POST类型的CSRF
如图解所示
三、如何防御CSRF
1、提交验证码
在表单中添加一个随机的数字或字母验证码。通过强制用户和应用进行交互。来有效地遏制CSRF攻击。
2、Referer Check
检查假设是非正常页面过来的请求，则极有可能是CSRF攻击。
3、token验证
（1）在 HTTP 请求中以參数的形式添加一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token，假设请求中没有 token 或者 token 内容不对，则觉得可能是 CSRF 攻击而拒绝该请求。
（2）token必须足够随机
（3）敏感的操作应该使用POST，而不是GET。比如表单提交。
4、在HTTP头中自己定义属性并验证
这样的方法也是使用 token 并进行验证。这里并非把 token 以參数的形式置于 HTTP 请求之中，而是把它放到 HTTP 头中自己 定义的属性里。通过 XMLHttpRequest 这个类，能够一次性给全部该类请求加上 csrftoken 这个 HTTP 头属性。并把 token 值放入当中。这样攻克了上种方法在请求中添加 token 的不便。同一时候，通过 XMLHttpRequest 请求的地址不会被记录到浏览器的地址栏，也不用操心 token 会透过 Referer 泄露到其它站点中去。
四、关于web跨域Post使用token思路
1、移动端登录时，服务端验证表单信息。登录成功，生成token，返回给client
2、client将token存在localstorage/sessionstorage中，每次提交表单，必须要携带token
3、服务端获取请求，如果没有token忽略请求