1. CSRF实例
CSRF攻击的主要目的是让用户在不知情的情况下攻击自己已登录的一个系统，类似于钓鱼。如用户当前已经登录了邮箱，或bbs，同时用户又在使用另外一个，已经被坦碧你控制的站点，我们姑且叫它钓鱼网站。这让逗举个网站上面可能因为某个图片吸引你，你去点击一下，此时可能就会触发一个js的点击事件，构造一个bbs发帖的请求，去往你的bbs发帖，由于当前你的浏览器状态已经是登陆状态，所以session登陆cookie信息都会跟正常的请求一样，纯天然的利用当前的登陆状态，让用户在不知情的情况下，帮你发帖或干其他事情。
一句话就是我们利用CSRF攻击就是借用用户的身份去执行用户的操作
先看一个例子（白帽子讲web安全），一个删除搜狐博客的例子，利用CSRF删除搜狐博客。
正常情况下，登陆搜狐博客后，只需请求这个url，就能把编号156713012的博客文章删除
我们尝试利用CSRF漏洞，删除编号为“156714243”的博客文章。这篇文章标题“test1”.
攻击者首先在自己的域构造一个页面：
其内容;
使用了一个<img>标签，其地址指向了删除博客文章的链接。
攻击者诱使目标用户，也就是博客主人“test1test”访问这个页面：
该用户会看到一张无法显示的图片，也就是<img>标签创造的图片，但无法显示，然后回头看搜狐博客：
发现原来存在的标题为‘’test1”的文章，已被删除。
这个删除博客攻击文章的请求，是攻击者伪造的，所以这种攻击就叫做“跨站点请求伪造”。
下面仿照以上做一个实例，这里利用自己的简单留言板实施一次CSRF攻击
前面我们已经讲过了，CSRF攻击是在用户登录状态下，利用用户身份执行操作，这里就用到了cookie,当用户正在访问留言板时，诱导用户去点开攻击者伪造的一个网页（有删除留言的指令），用户点开之后便带着原来的留言板cookie去执行删除留言这条指令，当用户返回之后发现原来留言信息没了。
这是登录界面，输入用户名进去后
看一下用户的cookie吧
当然这里是自己的cookie，已经能看到了指谈。
可以看到是post请求以表单的形式提交到delete.php，执行删除操作找到表单提交的name="ids",也就是ids=1时，我们可以删除id=1的留言，因为是POST请求，不能用标签的src属性，所以需要构建一个POST请求。
攻击者在自己的服务器中建立一个HTML文件csrf.html，用JS自动提交POST请求的form表单
这个只是本地测试，现在删除第三条留言，这个时候只要诱导用户去访问 http://127.0.0.1/Myphp/csrf.html 就会删除该留言，至于用什么方法，需要攻击者去精心构造了，只要想象力丰富，就能发挥CSRF强大的破坏力。
当用户在登录留言板状态下去访问该网页，，，，
原来的留言没了
这就是基本的CSRF攻击。。
2. CSRF（跨域请求伪造）
跨站请求攻击，简单地说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并执行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去执行。这利用了web中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。
你这可以这么理解CSRF攻击： 攻击者盗用了你的身份，以你的名义发送恶意请求。 CSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账……造成的问题包括：个人隐私泄露以及财产安全。
从上图可以看出，要完成一次CSRF攻击，受害者必须依次完成两个步骤：
登录受信任网站A，并在本地生成Cookie。
在不登出A的情况下，访问危险网站B。
看到这里，你也许会说：“如果我不满足以上两个条件中的一个，我就不会受到CSRF的攻击”。是的，确实如此，但你不能保证以下情况不会发生：
1.你不能保证你登录了一个网站后，不再打开一个tab页面并访问另外的网站。
2.你不能保证你关闭浏览器了后，你本地的Cookie立刻过期，你上次的会话已经结束。
3.上图中所谓的攻击网站，可能是一个存在其他漏洞的可信任的经常被人访问的网站。
1.提交验证码
在表单中增加一个随机的数字或字母验证码，通过强制用户和应用进行交互，来有效地遏制CSRF攻击。
2.Referer Check（referer：标志请求来源）
检查如果是非正常页面过来的请求，则极有可能是CSRF攻击。
3.token验证
在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token，如果请求中没有
token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求。
token需要足够随机
敏感的操作应该使用POST，而不是GET，以form表单的形式提交，可以避免token泄露。
4. 在 HTTP 头中自定义属性并验证
这种方法也是使用 token 并进行验证，这里并不是把 token 以参数的形式置于 HTTP 请求之中，而是液春把它放到 HTTP 头中自定义的属性里。通过 XMLHttpRequest 这个类，可以一次性给所有该类请求加上 csrftoken 这个 HTTP 头属性，并把 token 值蠢埋扰放入其中。这样解决了上种方法在请求中加入 token 的不便带旦，同时，通过 XMLHttpRequest 请求的地址不会被记录到浏览器的地址栏，也不用担心 token 会透过 Referer 泄露到其他网站中去。
csrf过滤器：
referer检查如果是非正常页面过来的请求，则极有可能是CSRF攻击。
自定义请求头“supporter”，根据电话、邮箱、日期、特殊字符、base64前台加密，后台过滤器解析。
3. CSRF攻击简介
CSRF（Cross Site Request Forgery），中文翻译为跨站请求欺骗攻击，是一种利用了浏览器漏洞的一种攻击手段，常被黑客用作刷接口的手段。
Cookie是保存在浏览器本地的一些数据，通常服务器会将和用户有关的数据，如登录token存放在Cookie中。浏览器有一套对Cookie的保护措施，比如Cookie按域（domain）存储，Cookie在别的域下是不可见的。
浏览器中的Cookie按照域（Domain）存储，不同域下的Cookie彼此不可见。但是从别的域下发来的请求却能带上这个域的Cookie。带上Cookie是好事，但不可避免的产生一些坏结果，因为Cookie中往往存储了用户的登录token，这使得来自别的域的请求自动处于登录状态，这意味着别的域的请求能模拟用户做出任何事情，比如批量发帖，批量删帖等。
小明是某某社区的用户
虽然跨域请求能带上Cookie，但请求前却无法看到Cookie中的内容，那么我们只要在Cookie中加上一个字段（X-CSRF-TOKEN）并在别的地雹轮方如Header中加上一个一模一样的字段，在服务器收到请求时校验这两个字段是否一致，便能防御CSRF攻击。
生成X-CSRF-TOKEN有两种策略：
1.在登录时由服务器下发给Cookie。
2.前端通过随机数生成，当发送请求时，发现Cookie中没有X-CSRF-TOKEN字段，便给Cookie加上该字段。
实践时我采用了前端随机生成Token的方法，实现过程中也遇到了一些问题。
1.如何生产Token
通过随机数生成的Token实际上就是时间戳。这种随机数是可以被碰撞攻击的。比如用户生成了Token就被CSRF，那CSRF中携带的Token完全可能野卖与我们生成的Token一致。解决方法是通过服务器下发的登录Token+时间戳做一个md5作为X-CSRF-TOKEN。
但这由带来了另一个问题，像登录Token这种重要的数据应该设置为http only，即js不可见，这样才能避免另外一些攻击，因此最好的办法实际是采用服务器下发Token的方式。
2.token放在header中还是放在body里
将Token放在Header中当然是最好的，但在实践中，使用自定义的Header会带来一些跨域的问题。颂肆逗浏览器在遇到跨域并且请求中有自定义Header时，首先它会向服务器发送一个Options请求来获取服务器的跨域策略，即response中的那几个header：
Access-Control-Allow-Origin
Access-Control-Allow-Methods
Access-Control-Allow-Credentials
Access-Control-Allow-Headers
因此在服务端我们要在Access-Control-Allow-Methods中加上Options，在Access-Control-Allow-Headers中加上X-CSRF-TOKEN。
然而这还不够，发送Options请求很有可能会失败，如果你有nginx的话。nginx可能会直接将Options请求给拦下来，导致之后的请求无法执行。