Csrf攻击以及防御的方法

一.csrf是什么？

csrf中文名称：跨站（域名）请求伪造。

二.可以做什么？

我们可以简单的这样理解，攻击者盗用了你的身份，借用你的名义发送恶意的请求，达到非法行为。类似于以你名义发送邮件，发送消息，银行转账，购买商品进行恶意消费等等。

三.如何实现的？

实现原理图，图片转自陈曦明博客园

clipboard.png

流程：
登录受信任的网站A，网站A会在用户C处生成一个Cookies。
此时用户C访问了一个位置的网站B，（比如点击网站B中一张图片，该图片指向用户C，并包含一个请求）
此时C的浏览器中的COOKIES并未过期，此时携带者C的COOKIES访问A，此时A不知道该请求是B发出的，根据A的权限处理。

那么问题来了
1.登录受信任网站，生成本地的
2.在不登出A的情况下，访问危险网站B
“如果我不满足以上两个条件中的一个，我就不会受到CSRF的攻击?

答案是不确定的！

1.首先我们不能保证关闭浏览器时候，上次的会话已经结束。
2.我们不能保证登录一个网站后不再登录另一个网站（通常我们不会这么做，而且这样做很低效）。
3.我们不能保证我们访问的网站是否已经被攻击。

原因（Why？）

银行网站A违反了HTTP规范，使用GET请求更新资源。在访问危险网站B的之前，你已经登录了银行网站A，而B中的以GET的方式请求第三方资源（这里的第三方就是指银行网站了，原本这是一个合法的请求，但这里被非法利用了），所以你的浏览器会带上你的银行网站A的Cookie发出Get请求，去获取资源“http://www.mybank.com/Transfer.php?toBankId=11&money=1000”，结果银行网站服务器收到请求后，认为这是一个更新资源操作（转账操作），所以就立刻进行转账操作......
那么GET请求造成这个问题，转换POST请求会不会解决问题。
为了杜绝上面的问题，银行决定改用POST请求完成转账操作。
银行网站A的WEB表单如下：

　　
　　　　ToBankId: 
　　　　Money:

后台处理页面Transfer.php如下：

危险网站B，仍然只是包含那句HTML代码：
　
　　
和示例1中的操作一样，你首先登录了银行网站A，然后访问危险网站B，结果.....和示例1一样，你再次没了1000块～T_T，这次事故的原因是：银行后台使用了$_REQUEST去获取请求的数据，而$_REQUEST既可以获取GET请求的数据，也可以获取POST请求的数据，这就造成了在后台处理程序无法区分这到底是GET请求的数据还是POST请求的数据。在PHP中，可以使用$_GET和$_POST分别获取GET请求和POST请求的数据。在JAVA中，用于获取请求数据request一样存在不能区分GET请求数据和POST数据的问题。

那么获取请求数据的方法改了会不会解决问题？

改用$_POST，只获取POST请求的数据，后台处理页面Transfer.php代码如下：

然而，危险网站B与时俱进，它改了一下代码：

 
　　
　　　　
　　

　　
　　　　
　　　　　　<form method="POST" name="transfer"　action="http://www.myBank.com/Transfer.php">
　　　　　　　　<input type="hidden" name="toBankId" value="11">
　　　　　　　　<input type="hidden" name="money" value="1000">
　　　　　　</form>

如果用户仍是继续上面的操作，很不幸，结果将会是再次不见1000块......因为这里危险网站B暗地里发送了POST请求到银行!
　　总结一下上面3个例子，CSRF主要的攻击模式基本上是以上的3种，其中以第1,2种最为严重，因为触发条件很简单，一个就可以了，而第3种比较麻烦，需要使用JavaScript，所以使用的机会会比前面的少很多，但无论是哪种情况，只要触发了CSRF攻击，后果都有可能很严重。
　　理解上面的3种攻击模式，其实可以看出，CSRF攻击是源于WEB的隐式身份验证机制！WEB的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器，但却无法保证该请求是用户批准发送的。

5.如何防御：

1.服务端进行CSRF防御
　　服务端的CSRF方式方法很多样，但总的思想都是一致的，就是在客户端页面增加伪随机数。
　　(1).Cookie Hashing(所有表单都包含同一个伪随机值)：
　　这可能是最简单的解决方案了，因为攻击者不能获得第三方的Cookie(理论上)，所以表单中的数据也就构造失败了:>





　　在表单里增加Hash值，以认证这确实是用户发送的请求。

　　

　　

　　　　

　　　　

　　　　”>

然后在服务器端进行Hash值验证

这个方法个人觉得已经可以杜绝99%的CSRF攻击了，那还有1%呢....由于用户的Cookie很容易由于网站的XSS漏洞而被盗取，这就另外的1%。一般的攻击者看到有需要算Hash值，基本都会放弃了，某些除外，所以如果需要100%的杜绝，这个不是最好的方法。

2.验证码

这个方案的思路是：每次的用户提交都需要用户在表单中填写一个图片上的随机字符串，这个方案可以完全解决CSRF，但个人觉得在易用性方面似乎不是太好，但是验证码的输入确实不是很好的体验。

(3).One-Time Tokens(不同的表单包含一个不同的伪随机值)

在实现One-Time Tokens时，需要注意一点：就是“并行会话的兼容”。如果用户在一个站点上同时打开了两个不同的表单，CSRF保护措施不应该影响到他对任何表单的提交。考虑一下如果每次表单被装入时站点生成一个伪随机值来覆盖以前的伪随机值将会发生什么情况：用户只能成功地提交他最后打开的表单，因为所有其他的表单都含有非法的伪随机值。必须小心操作以确保CSRF保护措施不会影响选项卡式的浏览或者利用多个浏览器窗口浏览一个站点。