CSRF 是什么？
CSRF（Cross-site request forgery）跨站请求伪造，也被称为“One Click Attack”或者Session Riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与XSS非常不同，XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS更具危险性。
攻击通过在授权用户访问的页面中包含链接或者脚本的方式工作。例
CSRF(13张)
如：一个网站用户Bob可能正在浏览聊天论坛，而同时另一个用户Alice也在此论坛中，并且后者刚刚发布了一个具有Bob银行链接的图片消息。设想一下，Alice编写了一个在Bob的银行站点上进行取款的form提交的链接，并将此链接作为图片src。如果Bob的银行在cookie中保存他的授权信息，并且此cookie没有过期，那么当Bob的浏览器尝试装载图片时将提交这个取款form和他的cookie，这样在没经Bob同意的情况下便授权了这次事务。
CSRF是一种依赖web浏览器的、被混淆过的代理人攻击（deputy attack）。在上面银行示例中的代理人是Bob的web浏览器，它被混淆后误将Bob的授权直接交给了Alice使用。
下面是CSRF的常见特性：
依靠用户标识危害网站
利用网站对用户标识的信任
欺骗用户的浏览器发送HTTP请求给目标站点
另外可以通过IMG标签会触发一个GET请求，可以利用它来实现CSRF攻击。
风险在于那些通过基于受信任的输入form和对特定行为无需授权的已认证的用户来执行某些行为的web应用。已经通过被保存在用户浏览器中的cookie进行认证的用户将在完全无知的情况下发送HTTP请求到那个信任他的站点，进而进行用户不愿做的行为。
使用图片的CSRF攻击常常出现在网络论坛中，因为那里允许用户发布图片而不能使用JavaScript。
贴图只是GET的方式，很多时候我们需要伪造POST的请求。一个办法是利用跨站，当然目标站点可能不存在跨站，这个时候我们可以从第三方网站发动攻击。
比如我要攻击一个存在问题的blog，那就先去目标blog留言，留下一个网址，诱其主人点击过来（这个就要看你的忽悠本事咯:p），然后构造个HTML表单提交些数据过去。
多窗口浏览器就帮了一点忙。
多窗口浏览器（firefox、遨游、MyIE……）便捷的同时也带来了一些问题，因为多窗口浏览器新开的窗口是具有当前所有会话的。即我用IE登陆了我的Blog，然后我想看新闻了，又运行一个IE进程，这个时候两个IE窗口的会话是彼此独立的，从看新闻的IE发送请求到Blog不会有我登录的cookie；但是多窗口浏览器永远都只有一个进程，各窗口的会话是通用的，即看新闻的窗口发请求到Blog是会带上我在blog登录的cookie。
想一想，当我们用鼠标在Blog/BBS/WebMail点击别人留下的链接的时候，说不定一场精心准备的CSRF攻击正等着我们。
对于web站点，将持久化的授权方法（例如cookie或者HTTP授权）切换为瞬时的授权方法（在每个form中提供隐藏field），这将帮助网站防止这些攻击。一种类似的方式是在form中包含秘密信息、用户指定的代号作为cookie之外的验证。
另一个可选的方法是“双提交”cookie。此方法只工作于Ajax请求，但它能够作为无需改变大量form的全局修正方法。如果某个授权的cookie在form post之前正被JavaScript代码读取，那么限制跨域规则将被应用。如果服务器需要在Post请求体或者URL中包含授权cookie的请求，那么这个请求必须来自于受信任的域，因为其它域是不能从信任域读取cookie的。
与通常的信任想法相反，使用Post代替Get方法并不能提供卓有成效的保护。因为JavaScript能使用伪造的POST请求。尽管如此，那些导致对安全产生“副作用”的请求应该总使用Post方式发送。Post方式不会在web服务器和代理服务器日志中留下数据尾巴，然而Get方式却会留下数据尾巴。
尽管CSRF是web应用的基本问题，而不是用户的问题，但用户能够在缺乏安全设计的网站上保护他们的帐户：通过在浏览其它站点前登出站点或者在浏览器会话结束后清理浏览器的cookie。
CSRF攻击依赖下面的假定：
攻击者了解受害者所在的站点
攻击者的目标站点具有持久化授权cookie或者受害者具有当前会话cookie
目标站点没有对用户在网站行为的第二授权
从一个故事说起（故事纯属虚构，模仿后果自负）：
小谷最近遭遇电信诈骗被骗的倾家荡产，于是他想到了报复社会。在知乎上狂点800个没有帮助1000个举报后，他决定做点正事干票捞钱的生意。 「很多视频网站都有赠送礼品的功能，假如所有人都赠送我个礼物，我再转卖掉，不就发财啦」小谷寻思着。 说干就敢，经过一番折腾测试，小谷发现视频网站赠送礼物的接口是:
， 原来只要用户在登录状态下请求这个地址，就能给名为someone的用户赠送礼品ab231。 那如何才能让其他用户请求这个接口呢？其实只要用户点击就行，「色诱是最好的陷阱」回想起自己被骗的经过，小谷猥琐狠狠的打了一行文字 ——「想要的都在这里，今夜注定让你无眠~~ 饥人谷-最有爱的前端学习社区」，然后在各个群组里回复。 经过一天等待，有几个上钩的，但远远达不到预期，「有没有更自动的办法，让用户只要看到即使不点也能上钩呢？」。小谷开始对整个网站功能逐一过滤，突然他眼前一亮，在用户评论编辑框内看到了上传外链图片的功能。「如果把这个 url 作为图片填进去，上传后会在评论区创建一个img 标签，src 对应的就是这个地址。当用户打开页面后这个 img 就会自动加载图片也就是发送这个请求，这样一来凡是打开这个页面的人不论是不是点击这个链接都会给赠送礼物，perfect!」 小谷为自己的聪明才智惊叹。 又过了一天，果然源源不断的礼物送了过来。这个时候小谷隐隐有些担心起来，虽然礼物送的都很小，但赠送都是有历史记录的，用户查看历史记录肯定会起疑心，能不能帮用户删除这条赠送记录呢？经过测试，发现删除赠送记录的接口地址是
， 接口类型为POST，请求参数为 { giftId:"ab231"}。 用户无法通过点击一个链接在不知情的情况下发送 POST 请求，怎么办呢？于是，小谷构造了一个页面：
当用户点开这个页面的链接后，会自动发送 POST 请求，然后跳转到原始首页。这样用户既在不知情的情况下赠送了礼品，又在不知情的情况下删除了赠送记录。大功告成后，小谷购买了个广告机在各大论坛狂发.... 一周之后，jc叔叔来敲门了，咚
上面小谷的攻击流程就是典型的 CSRF (Cross Site Request Forgery)攻击，中文名：跨站请求伪造。其原理是攻击者构造网站后台某个功能接口的请求地址，诱导用户去点击或者用特殊方法让该请求地址自动加载。用户在登录状态下这个请求被服务端接收后会被误以为是用户合法的操作。对于 GET 形式的接口地址可轻易被攻击，对于 POST 形式的接口地址也不是百分百安全，攻击者可诱导用户进入带 Form 表单可用POST方式提交参数的页面。
后续......
xxxx视频网站不断接到用户举报，自己的礼品莫名丢失。经过排查发现有攻击者利用 CSRF 进行攻击，报警后赶紧让公司的安全部门的小饥来修复漏洞。 小饥梳理了一遍公司网站所有的接口，发现很多接口都存在这个问题。于是采用了anti-csrf-token的方案。 具体方案如下：
服务端在收到路由请求时，生成一个随机数，在渲染请求页面时把随机数埋入页面（一般埋入 form 表单内，<input type="hidden" name="_csrf_token" value="xxxx">）
服务端设置setCookie，把该随机数作为cookie或者session种入用户浏览器
当用户发送 GET 或者 POST 请求时带上_csrf_token参数（对于 Form 表单直接提交即可，因为会自动把当前表单内所有的 input 提交给后台，包括_csrf_token）
后台在接受到请求后解析请求的cookie获取_csrf_token的值，然后和用户请求提交的_csrf_token做个比较，如果相等表示请求是合法的。
（上图是某电商网站的真实设置，这里页面上设置的 token和session里设置的token 虽然不直接相等，但 md5('1474357164624') === '4bd4e512b0fbd9357150649adadedd4e'，后台还是很好计算的）
安全部的Leader 看了看小饥的方案，「方案出的很赞， 不过还有几点需要注意一下」：
Token 保存在 Session 中。假如 Token 保存在 Cookie 中，用户浏览器开了很多页面。在一些页面 Token 被使用消耗掉后新的Token 会被重新种入，但那些老的 Tab 页面对应的 HTML 里还是老 Token。这会让用户觉得为啥几分钟前打开的页面不能正常提交？
尽量少用 GET。假如攻击者在我们的网站上传了一张图片，用户在加载图片的时候实际上是向攻击者的服务器发送了请求，这个请求会带有referer表示当前图片所在的页面的 url。 而如果使用 GET 方式接口的话这个 URL 就形如：，那相当于攻击者就获取了_csrf_token，短时间内可以使用这个 token 来操作其他 GET 接口。
CSRF(Cross Site Request Forgery)即跨站请求伪造。就是利用后台有规律的接口，例如 localhost/deleteAriticle.php?id=3&username=xiaoxiao，攻击者在被攻击的网站页面嵌入这样的代码，当用户xiaoxiao访问该网站的时候，会发起这条请求。服务器会删除id为3的数据。 客户端防范：对于数据库的修改请求，全部使用POST提交，禁止使用GET请求。 服务器端防范：一般的做法是在表单里面添加一段隐藏的唯一的token(请求令牌)。
有个很好玩的栗子 https://网页链接gin?act=exit
1、简介
CSRF的全名为Cross-site request forgery，它的中文名为 跨站请求伪造（伪造跨站请求【这样读顺口一点】）
CSRF是一种夹持用户在已经登陆的web应用程序上执行非本意的操作的攻击方式。相比于XSS，CSRF是利用了系统对页面浏览器的信任，XSS则利用了系统对用户的信任。
2、CSRF攻击原理
下面为CSRF攻击原理图：
由上图分析我们可以知道构成CSRF攻击是有条件的：
1、客户端必须一个网站并生成cookie凭证存储在浏览器中
2、该cookie没有清除，客户端又tab一个页面进行访问别的网站
3、CSRF例子与分析
我们就以游戏虚拟币转账为例子进行分析
3.1、简单级别CSRF攻击
假设某游戏网站的虚拟币转账是采用GET方式进行操作的，样式如：
此时恶意攻击者的网站也构建一个相似的链接：
1、可以是采用图片隐藏，页面一打开就自动进行访问第三方文章：<img src='攻击链接'>
2、也可以采用js进行相应的操作
1、假若客户端已经验证并登陆www.game.com网站，此时客户端浏览器保存了游戏网站的验证cookie
2、客户端再tab另一个页面进行访问恶意攻击者的网站，并从恶意攻击者的网站构造的链接来访问游戏网站
3、浏览器将会携带该游戏网站的cookie进行访问，刷一下就没了1000游戏虚拟币
3.2、中级别CSRF攻击
游戏网站负责人认识到了有被攻击的漏洞，将进行升级改进。
将由链接GET提交数据改成了表单提交数据
Transfer.php
恶意攻击者将会观察网站的表单形式，并进行相应的测试。
首先恶意攻击者采用（http://www.game.com/Transfer.php?toUserId=20&vMoney=1000）进行测试，发现仍然可以转账。
那么此时游戏网站所做的更改没起到任何的防范作用，恶意攻击者只需要像上面那样进行攻击即可达到目的。
总结：
1、网站开发者的错误点在于没有使用$_POST进行接收数据。当$_REQUEST可以接收POST和GET发来的数据，因此漏洞就产生了。
3.3、高级别CSRF攻击
这一次，游戏网站开发者又再一次认识到了错误，将进行下一步的改进与升级，将采用POST来接收数据
Transfer.php
此时恶意攻击者就没有办法进行攻击了么？那是不可能的。
恶意攻击者根据游戏虚拟币转账表单进行伪造了一份一模一样的转账表单，并且嵌入到iframe中
嵌套页面：(用户访问恶意攻击者主机的页面，即tab的新页面)
表单页面：（csrf.html）
客户端访问恶意攻击者的页面一样会遭受攻击。
总结：
CSRF攻击是源于Web的隐式身份验证机制！Web的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器，但却无法保证该请求是用户批准发送的
4、CSRF防御方法
服务器端防御：
1、重要数据交互采用POST进行接收，当然是用POST也不是万能的，伪造一个form表单即可破解
2、使用验证码，只要是涉及到数据交互就先进行验证码验证，这个方法可以完全解决CSRF。但是出于用户体验考虑，网站不能给所有的操作都加上验证码。因此验证码只能作为一种辅助手段，不能作为主要解决方案。
3、验证HTTP Referer字段，该字段记录了此次HTTP请求的来源地址，最常见的应用是图片防盗链。PHP中可以采用APache URL重写规则进行防御，可参考：http://www.cnblogs.com/phpstudy2015-6/p/6715892.html
4、为每个表单添加令牌token并验证
（可以使用cookie或者session进行构造。当然这个token仅仅只是针对CSRF攻击，在这前提需要解决好XSS攻击，否则这里也将会是白忙一场【XSS可以偷取客户端的cookie】）
CSRF攻击之所以能够成功，是因为攻击者可以伪造用户的请求，该请求中所有的用户验证信息都存在于Cookie中，因此攻击者可以在不知道这些验证信息的情况下直接利用用户自己的Cookie来通过安全验证。由此可知，抵御CSRF攻击的关键在于：在请求中放入攻击者所不能伪造的信息，并且该信息不存在于Cookie之中。
鉴于此，我们将为每一个表单生成一个随机数秘钥，并在服务器端建立一个拦截器来验证这个token，如果请求中没有token或者token内容不正确，则认为可能是CSRF攻击而拒绝该请求。
由于这个token是随机不可预测的并且是隐藏看不见的，因此恶意攻击者就不能够伪造这个表单进行CSRF攻击了。
要求：
1、要确保同一页面中每个表单都含有自己唯一的令牌
2、验证后需要删除相应的随机数
构造令牌类Token.calss.php
表单中使用：
验证：
该方法套路：
1. 用户访问某个表单页面。
2. 服务端生成一个Token，放在用户的Session中，或者浏览器的Cookie中。【这里已经不考虑XSS攻击】
3. 在页面表单附带上Token参数。
4. 用户提交请求后， 服务端验证表单中的Token是否与用户Session（或Cookies）中的Token一致，一致为合法请求，不是则非法请求。
5、参考文献
1. 《http://www.cnblogs.com/hyddd/archive/2009/04/09/1432744.html》
2. 《http://www.cnblogs.com/lovesong/p/5233195.html》
（以上是作者自己的一些见解，若有不足或者错误的地方请各位指出）
作者：那一叶随风 http://www.cnblogs.com/phpstudy2015-6/
原文地址：http://www.cnblogs.com/phpstudy2015-6/p/6771239.html
CSRF验证失败. 相应中断.
1）.首先，我们可以先看一下出现问题的所在的原因。
Your browser is accepting cookies.
The view function passes a request to the template's render method.
In the template, there is a {% csrf_token %} template tag inside each POST form that targets an internal URL.
If you are not using CsrfViewMiddleware, then you must use csrf_protect on any views that use the csrf_token template tag, as well as those that accept the POST data.
2），不难发现，我们是在上面的问题中有一个{% csrf_token %}，这是一个网络漏洞，在所有的表单的提交中，都需要添加，而且，必须放在format 后面。
接着，我们应该查找一下seting 中的MIDDLEWARE_CLASSES 是否缺少了 django.middleware.csrf.CsrfViewMiddleware这也可能是造成出错的原因。
3）.在app 中的views 中可以添加一个from django.template import RequestContext，然后，渲染函数render添加即可。例如：return render(req,'df_user/login.html',context_instance=RequestContext(req))。
以上，就是出现问题的三种解决办法，希望可以帮到你。
