CSRF（Cross-site request forgery）跨站请求伪造，由于目标站无token/referer限制，导致攻击者可以用户的身份完成操作达到各种目的。根据HTTP请求方式，CSRF利用方式可分为两种。
我们先来看看CSRF和XSS的工作原理，先让大家把这两个分开来。
XSS：攻击者发现XSS漏洞——构造代码——发送给受害人——受害人打开——攻击者获取受害人的cookie——完成攻击
CSRF：攻击者发现CSRF漏洞——构造代码——发送给受害人——受害人打开——受害人执行代码——完成攻击
举个例子来说吧(受害者的网址是a.cn，攻击者的网址是b.cn)攻击者想要在某个网站(网站是某个开源CMS)添加上另一个管理员，但是这个网站并没有XSS漏洞。怎么办呢？这时攻击者发现了这个开源CMS后台添加管理员时并没有加入验证码或则token，只需要输入要添加的管理员账号和密码点击确定就可以添加管理员账户了。这时和我一样聪明的攻击者在自己的服务器上建立了一个html文件(假设地址是b.cn/index.html)。然后就给网站管理员发邮件等等，诱使管理员打开b.cn/index.html。当管理员打开后（这时管理员正在网站后台，或则管理员的session并没有失效的话），就可以神不知鬼不觉的在网站后台添加了一个管理员账户。
1、GET类型的CSRF
这种类型的CSRF一般是由于程序员安全意识不强造成的。GET类型的CSRF利用非常简单，只需要一个HTTP请求，所以，一般会这样用：
<img src=>
在访问含有这个img的页面后，成功向。
（1）场景一：在一个bbs社区里，用户在发言的时候会发出一个这样的GET请求：GET /talk.php?msg=hello HTTP/1.1Host: www.bbs.com…Cookie: PHPSESSID=ee2cb583e0b94bad4782ea这是用户发言内容为“hello”时发出的请求，当然，用户在请求的同时带上了该域下的cookie，于是攻击者构造了下面的csrf.html页面：<html><img src=http://www.bbs.com/talk.php?msg=goodbye /></html>可以看到，攻击者在自己的页面中构造了一个发言的GET请求，然后把这个页面放在自己的服务器上，链接为http://www.evil.com/csrf.html。之后攻击者通过某种方式诱骗受害者访问该链接，如果受害者此时处于登录状态，就会带上bbs.com域下含有自己认证信息的cookie访问http://www.bbs.com/talk.php?msg=goodbye,结果就是受害者按照攻击者的意愿提交了一份内容为“goodbye”的发言。有人说这有什么大不了的，好，我们再看看另一个场景下的CSRF攻击。
2、POST类型的CSRF
这种类型的CSRF危害没有GET型的大，利用起来通常使用的是一个自动提交的表单，
<form action=http://wooyun.org/csrf.php method=POST><input type="text" name="xx" value="11" /></form><script> document.forms[0].submit(); </script>
访问该页面后，表单会自动提交，相当于模拟用户完成了一次POST操作。
（2）场景二：在一个CMS系统的后台，发出下面的POST请求可以执行添加管理员的操作：POST /manage.php?act=add HTTP/1.1Host: www.cms.com…Cookie: PHPSESSID=ee2cb583e0b94bad4782ea;is_admin=234mn9guqgpi3434f9r3msd8dkekwel(空一行)uname=test&pword=test在这里，攻击者构造了的csrf2.html页面如下：<html><form action="/manage.php?act=add" method="post"><input type="text" name="uname" value="evil" /><input type="password" name="pword" value="123456" /></form><script>document.forms[0].submit();</script></html> 该页面的链接为。 通过这些场景我们可以看到，CSRF攻击会根据场景的不同而危害迥异。小到诱使用户留言，大到垂直越权进行操作。这些攻击的请求都是跨域发出,并且至关重要的一点，都是在受害者的身份得到认证以后发生的。另外，我们在第一个场景中攻击时并没有使用JavaScrpit，这说明CSRF攻击并不依赖于JavaScript。
3、CSRF攻击方式
1）、HTML CSRF攻击：
即利用HTML元素发出GET请求（带src属性的HTML标签都可以跨域发起GET请求），如：
<link href="…"><img src="…"><iframe src="…"><meta http-equiv="refresh" content="0; url=…"><script src="…"><video src="…"><audio src="…"><a href="…"><table background="…">
若要构造POST请求，则必须用表单提交的方式。另外，这些标签也可以用JavaScript动态生成，如：<script>new Image().src = 'http://www.goal.com/…';</script>
2）、JSON HiJacking攻击：
4、 CSRF的危害
前面说了CSRF的基本概念，列举了几个CSRF的攻击场景，讲述了几种CSRF的攻击方法，现在我们来简单总结一下CSRF攻击可能造成的危害。CSRF能做的事情大概如下：1）篡改目标网站上的用户数据；2）盗取用户隐私数据；3）作为其他攻击向量的辅助攻击手法；4）传播CSRF蠕虫。 其中前两点我们在之前的例子中已经做了比较详细的说明，不再赘述。第三点即将其他攻击方法与CSRF进行结合进行攻击，接下来我们以实际的漏洞实例来说明CSRF的第三个危害。 另外，CSRF蠕虫就是利用之前讲述的各种攻击方法，并且在攻击代码里添加了形成蠕虫传播条件的攻击向量，这一点会在本文的最后介绍。
5、如何修复
针对CSRF的防范，有以下几点要注意：关键操作只接受POST请求验证码CSRF攻击的过程，往往是在用户不知情的情况下构造网络请求。所以如果使用验证码，那么每次操作都需要用户进行互动，从而简单有效的防御了CSRF攻击。但是如果你在一个网站作出任何举动都要输入验证码会严重影响用户体验，所以验证码一般只出现在特殊操作里面，或者在注册时候使用检测refer常见的互联网页面与页面之间是存在联系的，比如你在www.baidu.com应该是找不到通往www.google.com的链接的，再比如你在论坛留言，那么不管你留言后重定向到哪里去了，之前的那个网址一定会包含留言的输入框，这个之前的网址就会保留在新页面头文件的Referer中通过检查Referer的值，我们就可以判断这个请求是合法的还是非法的，但是问题出在服务器不是任何时候都能接受到Referer的值，所以Refere Check 一般用于监控CSRF攻击的发生，而不用来抵御攻击。Token目前主流的做法是使用Token抵御CSRF攻击。下面通过分析CSRF 攻击来理解为什么Token能够有效CSRF攻击要成功的条件在于攻击者能够预测所有的参数从而构造出合法的请求。所以根据不可预测性原则，我们可以对参数进行加密从而防止CSRF攻击。另一个更通用的做法是保持原有参数不变，另外添加一个参数Token，其值是随机的。这样攻击者因为不知道Token而无法构造出合法的请求进行攻击。Token 使用原则Token要足够随机————只有这样才算不可预测Token是一次性的，即每次请求成功后要更新Token————这样可以增加攻击难度，增加预测难度Token要注意保密性————敏感操作使用post，防止Token出现在URL中
辅助：
HTTP Referer是header的一部分，当浏览器向web服务器发送请求的时候，一般会带上Referer，告诉服务器我是从哪个页面链接过来的，服务器籍此可以获得一个信息用于处理。比如从我主页上链接到一个朋友那里，他的服务器就能够从HTTP Referer中统计出每天有多少用户点击我主页上的链接访问他的网站。