下图为生成的HTML，可以看到{% raw %}{{% endraw %}% csrf_token %}这串代码被Django解析成了一个隐藏的input标签，其中的值为token值，当我们发送请求时必须带上这个值。
只有这样Django才会接受POST请求来的数据，否则返回错误，并且原登陆页面的CSRF_Token重新生成，上一个进行销毁，很大程度上防御住了POST请求的CSRF。
补充一张暴漫系列图，引用自先知社区《聊聊CSRF漏洞攻防----久等的暴漫》作者：farmsec：
首先肯定确定是否除Cookie外其他参数均可确定，即：无验证码，无Token等。
再者如果发现是Referer头判断的话，可以尝试是否可以绕过正则。
还有就是考虑能不能绕过Token，比如Url处的Token用加载攻击者服务器上的图片来获取。
最后可以考虑与XSS结合，如：攻击者使用iframe跨域，存在xss漏洞的网站插入的XSS执行代码为eval(window.name)，那么我们构造的iframe标签里可以添加个name属性与子页面进行通信，例子：wooyun-2015-089971。
2) 白盒查看是否有Token，验证码，Referer等不确定参数判断。
判断Referer的正则是否安全。
判断Token返回的位置是否为安全位置。
判断生成的Token是否足够随机，毫无规律。
从上到下挖掘难度依次递增
0x08 补充说明 1) HttpOnly CSRF攻击不受Cookie的HttpOnly属性影响。
如果一个网站存在XSS漏洞，那么以上针对CSRF的防御几乎失去了作用。
3) 关于Flash的内容鉴于Flash的凉势，这里暂不做研究以节省时间。
4) 目前CSRF形势就目前而言，CSRF这个沉睡的巨人颇有一番苏醒的意味，可导致的危害也正在逐步的为人们所知，但目前仍有许多开发人员还没有足够的安全意识，以为只要验证Cookie就能确定用户的真实意图了，这就导致了目前仍有大量潜在的CSRF漏洞的局面，CSRF是不可小觑的漏洞，希望大家看完这篇文章能对CSRF有个较为清晰的认识。
0x09 结束语虽说这篇文章内容较为基础，但也是我熟读几本相关书籍与相关文章、研究已知漏洞，所写出来的一篇半总结，半思考文章，也许里边会有些错误，麻烦各位表哥斧正，如果有想要与我交流相关内容的可以email我(asp-php#foxmail.com #换成@)。
0x0A 参考书籍：
《Web前端黑客技术揭秘》p83-p96
《XSS跨站脚本攻击剖析与防御》p182-p187
《黑客攻防技术宝典Web实战篇第二版》p368-p374
文章:
CSRF漏洞挖掘
WEB安全之Token浅谈
跨域方式及其产生的安全问题
Django中CSRF原理及应用详解
CSRF简单介绍及利用方法 | WooYun知识库
原生JSONP实现_动态加载js（利用script标签）