CSRF跨站点请求伪造

CSRF（Cross-site request forgery），中文名称：跨站请求伪造，也被称为：one click attack/session riding，缩写为：CSRF/XSRF。

CSRF攻击：攻击者盗用了你的身份，以你的名义发送恶意请求

例如：

你登陆了一个网站http://blog.sohu.com

然后你又访问了恶意的网站www.abc.com，他构造了一个恶意的请求去删除文章，

如http://blog.sohu.com/manage/entry.do?m=delete&id=123。当这个请求触发时，那么你的文章就会被删除。

为什么会使这种攻击成功呢？

因为当你登陆sohu时，cookie记录了你的登陆凭证。然后打开tab页，登陆恶意的网站，向sohu域发送请求，

会带上你的登陆凭证，这样就可以进行操作了。

1.因为cookie可以随同域名请求发送到服务器，恶意构造的请求就是和你登陆的域名一样。当然cookie分为session cookie

（临时cookie，在浏览器进程结束就消失）和third-party cookie(本地cookie，指定了失效时间)，当一个域下要加载另一个域的资源，

出于安全原因，有些浏览器会阻止third-party cookie发送。如IE。

2.同一浏览器进程的生命周期内，不同的tab网页cookie都是有效的。

CSRF防御

CSRF本质是黑客事先构造好恶意的请求，让用户在无意识下去点击。

1.验证码

当请求需要验证码时，黑客是无法构造当前的验证码是什么的，所以这样可以阻止CSRF攻击。不过由于验证码影响用户体验，

使用验证码只能算是一种解决办法。

2.Referer Check

Referer在http header中，他表示用户是由哪个页面发起的请求，这样服务端通过判断发起页面的来源，可以判断是否为CSRF攻击。

但是有些情况下，referer是不会发送的。

3.Token

CSRF能攻击成功的本质原因是重要操作的所有参数都是可以被攻击者猜到的。当把你的请求参数进行加密，或者使用一些随机数，

从而让攻击者无法猜测到参数值。但是加密或混淆后的url将变得非常难读，对用户不友好。如果加密后的参数每次都改变，

这样url也无法被用户收藏。同时，数据分析时常常用到明文参数，对数据分析工作带来很大的困扰。

token是一个解决问题的好办法

在请求的url中，加入一个参数token，只有客户端和服务端共同持有，不被第三者知晓。token可以存放在form表单中，

或者cookie，session中。当提交请求时，服务器只需要验证表单中的Token，与用户session的token或者cookie的token是否一致，

如果一致，则认为是合法请求，如果不一致，或者为空，则为不合法，可能发生了CSRF攻击。

那么把token存在form表单中，或者cookie中，安全吗？

1. 因为浏览器的安全机制，不同域的js是无法读取cookie的值的，所以黑客通过js获取cookie中的token是无法实现的。

2. 当然如果你把token存在了form中，但是页面受到了XSS攻击，这样也是有可能泄露token的。

token使用准则

1. token需要足够随机，不能被摸透

2. token如果出现在某个页面的url中，则可能通过Referer的方式泄露。因为如果当前页面下，包含了一张攻击者指定地址的图片，这样当前页面的url会当做请求的Referer值发送到evil.com的服务器，导致token泄露。

因此尽力把token放在表单中，把敏感操作由get改为post，以form表单的形式提交。

最后，CSRF的token只是用来对抗CSRF攻击，当网站还存在XSS漏洞时，这个方案就会变得无效，因为XSS可以模拟

客户端浏览器的执行任意操作。所以XSS的问题需要用XSS的解决方案予以解决。否则CSRF的token防御就是空中楼阁。