浅谈CSRF攻击方式

浅谈CSRF攻击方式目录1CSRF是什么2CSRF可以做什么3CSRF的原理4CSRF的防御CSRF是什么CSRF（Cross-siterequestforgery）中文名称：跨站请求伪造也被称为：oneclickattack/sessionriding缩写为：CSRF/XSRFCSRF可以做什么你可以这么理解CSRF攻击：攻击者盗用了你的身份，以你的名义发送恶意请求。CSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账......造成的问题包括：个人隐私泄露以及财产安全CSRF的原理下图简单阐述了CSRF攻击的思想：CSRF的原理从上图可以看出，要完成一次CSRF攻击，受害者必须依次完成两个步骤：1.登录受信任网站A，并在本地生成Cookie。2.在不登出A的情况下，访问危险网站B。看到这里，你也许会说：“如果我不满足以上两个条件中的一个，我就不会受到CSRF的攻击”。是的，确实如此，但你不能保证以下情况不会发生：1.你不能保证你登录了一个网站后，不再打开一个tab页面并访问另外的网站。2.你不能保证你关闭浏览器了后，你本地的Cookie立刻过期，你上次的会话已经结束。（事实上，关闭浏览器不能结束一个会话，但大多数人都会错误的认为关闭浏览器就等于退出登录/结束会话了......）3.上图中所谓的攻击网站，可能是一个存在其他漏洞的可信任的经常被人访问的网站。CSRF的原理示例一银行网站A，它以GET请求来完成银行转账的操作，如：=11&money=1000危险网站B，它里面有一段HTML的代码如下：imgsrc==11&money=1000首先，你登录了银行网站A，然后访问危险网站B，这时你会发现你的银行账户少了1000块......原因是银行网站A违反了HTTP规范，使用GET请求更新资源。在访问危险网站B之前，你已经登录了银行网站A，而B中的img以GET的方式请求第三方资源（这里的第三方就是指银行网站了，原本这是一个合法的请求，但这里被不法分子利用了），所以你的浏览器会带上你的银行网站A的Cookie发出Get请求，去获取资源“=11&money=1000”，结果银行网站服务器收到请求后，认为这是一个更新资源操作（转账操作），所以就立刻进行转账操作......CSRF的原理示例二银行网站A决定改用POST请求完成转账操作银行网站A的WEB表单如下：formaction=Transfer.phpmethod=POSTpToBankId:inputtype=textname=toBankId//ppMoney:inputtype=textname=money//ppinputtype=submitvalue=Transfer//p/form后台处理页面Transfer.php如下：?phpsession_start();if(isset($_REQUEST['toBankId']&&isset($_REQUEST['money'])){buy_stocks($_REQUEST['toBankId'],$_REQUEST['money']);}?CSRF的原理示例二危险网站B，仍然只是包含那句HTML代码：imgsrc==11&money=1000和示例1中的操作一样，你首先登录了银行网站A，然后访问危险网站B，结果.....和示例1一样，你再次没了1000块这次事故的原因是：银行后台使用了$_REQUEST去获取请求的数据，而$_REQUEST既可以获取GET请求的数据，也可以获取POST请求的数据，这就造成了在后台处理程序无法区分这到底是GET请求的数据还是POST请求的数据。在PHP中，可以使用$_GET和$_POST分别获取GET请求和POST请求的数据。在JAVA中，用于获取请求数据request一样存在不能区分GET请求数据和POST数据的问题。CSRF的防御CookieHashingCookieHashing(所有表单都包含同一个伪随机值)：这可能是最简单的解决方案了，因为攻击者不能获得第三方的Cookie(理论上)，所以表单中的数据也就构造失败了?php//构造加密的Cookie信息$value=“DefenseSCRF”;setcookie(“cookie”,$value,time()+3600);?在表单里增加Hash值，以认证这确实是用户发送的请求?php$hash=md5($_COOKIE['cookie']);?formmethod=POSTaction=transfer.phpinputtype=textname=toBankIdinputtype=textname=moneyinputtype=hiddenname=hashvalue=?=$hash;?inputtype=submitname=submitvalue=Submit/formCSRF的防御CookieHashing然后在服务器端进行Hash值验证?phpif(isset($_POST['check'])){$hash=md5($_COOKIE['cookie']);if($_POST['check']==$hash){doJob();}else{//...}}else{//...}?这个方法已经可以杜绝99%的CSRF攻击了，那还有1%呢....由于用户的Cookie很容易由于网站的XSS漏洞而被盗取，这就是另外的1%。一般的攻击者看到有需要算Hash值，基本都会放弃，但也会有特殊情况，所以如果需要100%的杜绝，这个不是最好的方法。CSRF的防御验证码验证码这个方案的思路是：用户每次提交都需要在表单中填写一个图片上的随机字符串。这个方案可以完全解决CSRF，但个人觉得在易用性方面似乎不是太好，还有听闻是验证码图片的使用涉及了一个被称为MHTML的Bug，可能在某些版本的微软IE中受影响。感谢您的关注Thanksforyourattention