有关网络攻击的CSRF

最近在工作做一个SSO,考虑很多网络安全方面的问题,看到一篇好文章,分享给大家:

一.CSRF是什么?

  CSRF(Cross-site request forgery),中文名称:跨站请求伪造,也被称为:one click attack/session riding,缩写为:CSRF/XSRF。

二.CSRF可以做什么?

  你这可以这么理解CSRF攻击:攻击者盗用了你的身份,以你的名义发送恶意请求。CSRF能够做的事情包括:以你名义发送邮件,发消息,盗取你的账号,甚至于购买商品,虚拟货币转账......造成的问题包括:个人隐私泄露以及财产安全。

三.CSRF漏洞现状

  CSRF这种攻击方式在2000年已经被国外的安全人员提出,但在国内,直到06年才开始被关注,08年,国内外的多个大型社区和交互网站分别爆出CSRF漏洞,如:NYTimes.com(纽约时报)、Metafilter(一个大型的BLOG网站),YouTube和百度HI......而现在,互联网上的许多站点仍对此毫无防备,以至于安全业界称CSRF为“沉睡的巨人”。

四.CSRF的原理

  下图简单阐述了CSRF攻击的思想:

  

  从上图可以看出,要完成一次CSRF攻击,受害者必须依次完成两个步骤:

  1.登录受信任网站A,并在本地生成Cookie。

  2.在不登出A的情况下,访问危险网站B。

  看到这里,你也许会说:“如果我不满足以上两个条件中的一个,我就不会受到CSRF的攻击”。是的,确实如此,但你不能保证以下情况不会发生:

  1.你不能保证你登录了一个网站后,不再打开一个tab页面并访问另外的网站。

  2.你不能保证你关闭浏览器了后,你本地的Cookie立刻过期,你上次的会话已经结束。(事实上,关闭浏览器不能结束一个会话,但大多数人都会错误的认为关闭浏览器就等于退出登录/结束会话了......)

  3.上图中所谓的攻击网站,可能是一个存在其他漏洞的可信任的经常被人访问的网站。

 

  上面大概地讲了一下CSRF攻击的思想,下面我将用几个例子详细说说具体的CSRF攻击,这里我以一个银行转账的操作作为例子(仅仅是例子,真实的银行网站没这么傻:>)

  示例1:

  银行网站A,它以GET请求来完成银行转账的操作,如:http://www.mybank.com/Transfer.php?toBankId=11&money=1000

  危险网站B,它里面有一段HTML的代码如下:

[html]  view plain copy print ? 在CODE上查看代码片 派生到我的代码片
  1. <img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>  
首先,你登录了银行网站A,然后访问危险网站B,噢,这时你会发现你的银行账户少了1000块......

  为什么会这样呢?原因是银行网站A违反了HTTP规范,使用GET请求更新资源。在访问危险网站B的之前,你已经登录了银行网站A,而B中的<img>以GET的方式请求第三方资源(这里的第三方就是指银行网站了,原本这是一个合法的请求,但这里被不法分子利用了),所以你的浏览器会带上你的银行网站A的Cookie发出Get请求,去获取资源“http://www.mybank.com/Transfer.php?toBankId=11&money=1000”,结果银行网站服务器收到请求后,认为这是一个更新资源操作(转账操作),所以就立刻进行转账操作......

  示例2:

  为了杜绝上面的问题,银行决定改用POST请求完成转账操作。

  银行网站A的WEB表单如下:

[html]  view plain copy print ? 在CODE上查看代码片 派生到我的代码片
  1. <form action="Transfer.php" method="POST">  
  2.   <p>ToBankId: <input type="text" name="toBankId" /></p>  
  3.   <p>Money: <input type="text" name="money" /></p>  
  4.   <p><input type="submit" value="Transfer" /></p>  
  5. </form>  

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

  1. <?php  
  2.     session_start();  
  3.     if (isset($_REQUEST['toBankId'] && isset($_REQUEST['money']))  
  4.     {  
  5.         buy_stocks($_REQUEST['toBankId'], $_REQUEST['money']);  
  6.     }  
  7.   ?>  


危险网站B,仍然只是包含那句HTML代码:

[html]  view plain copy print ? 在CODE上查看代码片 派生到我的代码片
  1. <img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>  

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

  示例3:

  经过前面2个惨痛的教训,银行决定把获取请求数据的方法也改了,改用$_POST,只获取POST请求的数据,后台处理页面Transfer.php代码如下:

  1. <?php  
  2.     session_start();  
  3.     if (isset($_POST['toBankId'] && isset($_POST['money']))  
  4.     {  
  5.         buy_stocks($_POST['toBankId'], $_POST['money']);  
  6.     }  
  7.   ?>  

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

  1. <html>  
  2.   <head>  
  3.     <script type="text/javascript">  
  4.       function steal()  
  5.       {  
  6.                iframe = document.frames["steal"];  
  7.                iframe.document.Submit("transfer");  
  8.       }  
  9.     </script>  
  10.   </head>  
  11.   
  12.   <body οnlοad="steal()">  
  13.     <iframe name="steal" display="none">  
  14.       <form method="POST" name="transfer" action="http://www.myBank.com/Transfer.php">  
  15.         <input type="hidden" name="toBankId" value="11">  
  16.         <input type="hidden" name="money" value="1000">  
  17.       </form>  
  18.     </iframe>  
  19.   </body>  
  20. </html>  

如果用户仍是继续上面的操作,很不幸,结果将会是再次不见1000块......因为这里危险网站B暗地里发送了POST请求到银行!

  总结一下上面3个例子,CSRF主要的攻击模式基本上是以上的3种,其中以第1,2种最为严重,因为触发条件很简单,一个<img>就可以了,而第3种比较麻烦,需要使用JavaScript,所以使用的机会会比前面的少很多,但无论是哪种情况,只要触发了CSRF攻击,后果都有可能很严重。

  理解上面的3种攻击模式,其实可以看出,CSRF攻击是源于WEB的隐式身份验证机制!WEB的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器,但却无法保证该请求是用户批准发送的!

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值