简介
跨站点请求伪造(Cross Site Request Forgery,CSRF)：攻击者首先在自己的域内创建一个页面，并伪造一个请求，然后诱使用户点击该页面，这样就以该用户的身份在第三方站点（攻击者构造的页面）执行了一次操作。
浏览器的cookie策略
攻击者伪造的请求之所以能够被服务器验证通过，是因为用户的浏览器成功的发送了cookie的缘故。
浏览器所持有的cookie分为两种：
- session cookie（又称临时cookie）
- third-party cookie（又称本地cookie）
两者的区别在于third-party cookie是服务器在set-cookie时指定了expire时间，只要到了expire时间cookie就会失效。所以这种cookie会保存在本地。而session cookie则没有指定expire时间，直到关闭浏览器后，session cookie才失效，他保存在浏览器进程的内存空间中。
有些浏览器，默认策略允许发送第三方cookie，所以能够成功发送用于认证的third-party cookie，CSRF攻击成功。而有些浏览器默认会拦截third-party cookie ，这样攻击者则需要精心构造攻击环境，比如诱使用户在当前浏览器先访问目标站点，使得session cookie有效，在实CSRF攻击。
P3P头的副作用
P3P Header 是W3C制定的一项关于隐私的标准，全称是“the platform for privacy preferences”
如果网站返回给浏览器的HTTP头中包含有P3P头，则在某种程度上来说，将允许浏览器发送第三方cookie，P3P头允许跨域访问隐私数据，从而可以跨域set-cookie成功。正因为P3P头目前在网站的应用中被广泛应用，因此在CSRF防御中不能依赖于浏览器对第三方cookie的拦截策略，不能心存侥幸。
构造get/post 请求
Flash CSRF
Flash有很多方式发起网络请求，包括POST、getURL、loadvars等。
CSRF Worm
即使没有XSS漏洞，仅仅是CSRF也能发起大规模蠕虫攻击。
CSRF的防御
验证码
CSRF的攻击过程，往往在用户不知情的的情况下构造了网络请求，而验证码则强制用户必须与应用进行交互，才能完成最终请求，但是有些时候出于用户体验考虑，网站不能给所有的操作都加上验证吗，因此验证码只能作为防御SCRF的一种辅助手段。
Referer Check
Referer Check在网络中常见的应用就是“防止图片盗链”。同理Referer Check也可以被用于检查请求是否来自合法的“源”。Referer Check的缺陷是：服务器并非什么时候都能取到Referer。
很多用户处于隐私保护的考虑，限制了Referer的发送，在某些情况下，浏览器也不会发送Referer，（列：从https跳转至HTTP，出于安全考虑，浏览器也不会发送Referer）；有些Flash的版本可以发送自定义Referer的头。因此我们无法依赖于Referer Check作为防御SCRF的主要手段，但是可以通过Referer Check来监控CSRF攻击的发生。
Anti CSRF Token
现在业界针对CSRF防御，一致做法是使用一个token。
CSRF的本质
CSRF能够攻击成功的本质原因是：重要操作的所有参数都是可以被攻击猜测到的。攻击者只有预测出URL的所有参数与参数值，才能成功的构造一个伪造的请求。
因此可以想到：把参数加密，或者使用一些随机数，从而让攻击者无法猜测到参数值，这是“不可预测性原则”的一种应用。
在URL中，保持原参数不变，新增一个参数token，这个token的值是随机的，这样由于token的存在，攻击者无法在构造出一个完整的URL实施CSRF攻击。
token需要同时放在表单和session中，再提交请求时，服务器只需验证表单中的token和用户session（或cookie）中的token是否一致，如果一致，则认为是合法请求；如果不一致，或者有一为空，则认为请求不合法，可能发生了CSRF攻击。
Token的使用原则
token的生成一定要足够随机。
可为token设置生命周期，可根据情况生成多个有效的token。
使用token时应注意token的保密性。
安全防御的体系是相辅相成，缺一不可的。
详情请参考书籍
摘自：《白帽子讲Web安全》 — 吴翰清
