原文地址：https://www.yuque.com/linshiding/xss2bk/roz39s
什么是CSRF
CSRF（Cross-site request forgery）跨站请求伪造，也被称为“One Click Attack”或者Session Riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与XSS非常不同，XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS更具危险性。
上面这一段是来自百度百科的一段话，这里我们需要注意两个点，一个是跨站，所谓的跨站，是指不是来自同一个站点的攻击，并不是指跨域，即使你的站点没有开启跨域请求，依然有可能受到CSRF攻击。另一个是伪造，说的正是CSRF的攻击特点：伪造真实用户请求，让服务端认为是合理的请求，这正是我们要防范的地方。
通俗易懂：网站对用户浏览器的信任
CSRF是怎么攻击的
这里举一个例子：
1.用户小明登录了某银行网站A。
2.小明向好友转了1000块钱，假设转钱的请求是：http://xxx.com/transfer?money=1000&to=123456 其中money为金钱数额，to为要转向的人的账户id，这里是小明好友的账户id。
3.小明在保持银行账户还在登录状态的情况下，打开了恶意网站B（具体为什么打开，可能网站B有一些比较吸引人的地方...）。
4.网站B在被访问的时候，页面脚本立即发送一个预先设置好的请求：http://xxx.com/transfer?money=1000&to=654321 这时就会用小明身份向账户654321转1000块钱，小明莫名其妙就少了1000块钱。
攻击原理
cookie是罪魁祸首，我们知道cookie保存在浏览器的时候，只有本网站可以访问到，第三发网站不访问不了的，我们也没有办法访问其他网站的cookie的，这在一定程度上保证了cookie的安全性。
我们在浏览器上发送HTTP请求的时候，浏览器会把该域名下的cookie带上，一并发送到服务器。那么问题就来了，浏览器并不管当前发送请求的是哪个网站，是在哪个页面上发送的请求，只要你请求的域名在浏览器里保存有cookie信息，浏览器都会一并给你带上。
下面我们来看看，浏览器是怎么样带上cookie的，我们先登录百度，然后在百度上搜索关键字“csrf”，看到浏览器发送了一个搜索相关的请求，并且带上了cookie信息，如下图。
这是请求到的结果数据：
接下里，我们把刚刚那个请求复制下来，然后我们在本地启动一个服务，设置一个页面，这个页面在被访问的时候，会发送刚刚我们复制下来的搜索“csrf”的请求，然后我们打开这个页面，可以看到请求成功的发送了，并且还带上了我们在百度搜索时候的一模一样的cookie信息，返回的内容也一样，如下图：
我们再来看看小明的案例，下图是小明案例的整个CSRF攻击的过程：
攻击的条件有两个：
1.小明处于登录状态
2.小明访问了恶意网站B
小明在登录了银行网站A之后，网站A会在浏览器写入cookie信息，以后的每次请求，都会带上这些cookie信息，来证明小明的身份。浏览器第一次发送的转账请求是小明亲自操作的，是合法的行为，而第二次发送的转账请求，是恶意网站发送的，是非法的行为，但服务器一直都认为是小明本人操作的，只是转账的对象不一样，都认为是合法行为，所以两次转账都成功了。
如何防范
知道了csef的攻击原理后，就可以做防范措施了。防范的原理很简单，只要不单单验证cookie信息来确认身份和合法性就可以防范了。目前的防范思路主要有两种:
1.验证请求来源，通过请求头的Referer或者Origin字段来判断来源。
2.生成随机的token，在请求的时候带上，在服务端验证token。
