沉睡的巨人:CSRF

沉睡的巨人:CSRF

  • 漏洞介绍

CSRF(Cross-site request forgery)跨站请求伪造,也被称为”One Click Attack”或者Session Riding,通常缩写为CSRF或者XSRF,是一种对网站的恶意利用。尽管听起来像跨站脚本(XSS),但它与XSS非常不同,XSS利用站点内的信任用户,而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。

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

  • 漏洞危害等级

中危

  • 攻击原理

跨站请求伪造(CSRF)的攻击原理比较简单,如图所示,攻击者发现CSRF漏洞——构造代码——发送给受害人——受害人打开——受害人执行代码——完成攻击


图1.CSRF攻击原理

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

  • 实例

在这里,我们模拟一个场景。如图是我们想要攻击的站点。


图2.攻击目标

经过前期信息搜集以后发现,得知该站点的CMS。


图3.识别到站点CMS

在经过一些列前期侦查的过程中发现该站点外部均没有明显的漏洞,在此情况下,我们从网上下载公开的CMS源码。利用公开源码搭建模拟环境,对此源码进行CSRF的漏洞挖掘。

手工检测的方法也比较简单。抓取一个正常请求的数据包,去掉Referer字段后再重新提交,如果该提交还有效,那么基本上可以确定存在CSRF漏洞。


图4.测试站点后台登录数据包

随着对CSRF漏洞研究的不断深入,不断涌现出一些专门针对CSRF漏洞进行检测的工具,如CSRFTester,CSRF Request Builder等。为了提高效率,我们通常会是使用工具进行攻击。这里以以CSRFTester工具为例。在测试站点的后台进行添加管理员操作并且抓包构造攻击的页面。


图5.后台添加管理员操作


图6.抓取数据包构造攻击页面


图7.构造页面的核心代码

构造出新的页面以后,将页面链接以钓鱼等方式发送给被攻击者。当攻击者一旦点击该链接,就会通过构造的攻击页面以被攻击者的身份完成对被攻击站点的操作。


图8.以用户身份完成操作

  • CSRF漏洞防御

针对跨站请求伪造(CSRF)的防御措施,主要分在服务端、客户端、安全设备三个方面进行防御。

  • 服务端的防御

    • 验证HTTP Referer字段

根据HTTP协议,在HTTP头中有一个字段叫Referer,它记录了该HTTP请求的来源地址。在通常情况下,访问一个安全受限页面的请求必须来自于同一个网站。比如这里的后台添加管理员账户操作是通过用户访问http://192.168.250.4:78/system/admin_manage.asp?name=value页面完成,用户必须先登录http://192.168.250.4:78/system/,然后通过点击页面上的按钮来触发添加管理员操作。当用户提交请求时,该操作请求的Referer值就会是提交数据按钮所在页面的URL。而如果攻击者要对该站点实施CSRF攻击,他只能在自己的网站构造请求,当用户通过攻击者的网站发送请求到被攻击站点时,该请求的Referer是指向攻击者的网站。因此,要防御CSRF攻击,被攻击站点只需要对于每一个操作请求验证其Referer值,如果是以http//192.168.250.4:78开头的域名,则说明该请求是来自该站点自己的请求,是合法的。如果Referer是其他网站的话,就有可能是CSRF攻击,则拒绝该请求。

  • 在请求地址中添加token并验证

CSRF攻击之所以能够成功,是因为攻击者可以伪造用户的请求,该请求中所有的用户验证信息都存在于Cookie中,因此攻击者可以在不知道这些验证信息的情况下直接利用用户自己的Cookie来通过安全验证。由此可知,抵御CSRF攻击的关键在于:在请求中放入攻击者所不能伪造的信息,并且该信息不存在于Cookie之中。鉴于此,系统开发者可以在HTTP请求中以参数的形式加入一个随机产生的token,并在服务器端建立一个拦截器来验证这个token,如果请求中没有token或者token内容不正确,则认为可能是CSRF攻击而拒绝该请求。

  • 在HTTP头中自定义属性并验证

自定义属性的方法也是使用token并进行验证,和前一种方法不同的是,这里并不是把token以参数的形式置于HTTP请求之中,而是把它放到HTTP头中自定义的属性里。通过XMLHttpRequest这个类,可以一次性给所有该类请求加上csrftoken这个HTTP头属性,并把token值放入其中。这样解决了前一种方法在请求中加入token的不便,同时,通过这个类请求的地址不会被记录到浏览器的地址栏,也不用担心token会通过Referer泄露到其他网站。

  • 用户端的防御

对于普通用户来说,学习并具备网络安全知识以防御网络攻击是不现实的。但若用户养成良好的上网习惯,则能够很大程度上减少CSRF攻击的危害。例如,用户上网时,不要轻易点击网络论坛、聊天室、即时通讯工具或电子邮件中出现的陌生链接或者图片;及时退出长时间不使用的已登录账户,尤其是系统管理员,应尽量在登出系统的情况下点击未知链接和图片。除此之外,用户还需要在连接互联网的计算机上安装合适的安全防护软件,并及时更新软件厂商发布的特征库,以保持安全软件对最新攻击的实时跟踪。

  • 安全设备的防御

由于从漏洞的发现到补丁的发布需要一定的时间,而且相当比例的厂商对漏洞反应不积极,再加之部分系统管理员对系统补丁的不够重视,这些都给了攻击者可乘之机。鉴于上述各种情况,用户可以借助第三方的专业安全设备加强对CSRF漏洞的防御。

CSRF攻击的本质是攻击者伪造了合法的身份,对系统进行访问。如果能够识别出访问者的伪造身份,也就能识别CSRF攻击。研究发现,有些厂商的安全产品能基于硬件层面对HTTP头部的Referer字段内容进行检查来快速准确的识别CSRF攻击。下图展示了这种防御方式的简图。


图9.安全设备防御CSRF

  • 总结

通过以上的实例和原理分析,我们可以简单了解到成功利用CSRF漏洞进行攻击需要具备两个先决条件:1、明确存在漏洞位置的操作;2、被攻击者访问恶意页面并进行操作。从两个先决条件来看,能够成功利用该漏洞比起诸如跨站脚本攻击、SQL注入等攻击就显得不那么”直接”了。并且如果单纯地利用此漏洞,即使攻击成功,攻击者也不会获取到用户的口令或cookie。因此该漏洞往往容易麻痹用户的警惕性,使用户不重视针对该漏洞的防护措施。但也正是因为这种特性,往往使攻击者攻击成功,就如跨站脚本攻击(XSS)刚开始提出来的时候不被重视一样。正如标题,CSRF就像一个沉睡的巨人,不被重视却又威胁巨大。