白帽子挖洞—跨站请求伪造(CSRF)篇

0x00介绍

CSRF(Cross-site

request forgery)跨站请求伪造,也被称为“One Click Attack”或者Session Riding,通常缩写为CSRF或者XSRF,是一种对网站的恶意利用。尽管听起来像跨站脚本(XSS),但它与XSS非常不同,XSS利用站点内的信任用户,而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。主要利用受害者尚未失效的身份认证信息(cookie、会话等),诱骗其点击恶意链接或者访问包含攻击代码的页面,在受害人不知情的情况下以受害者的身份向(身份认证信息所对应的)服务器发送请求,从而完成非法操作(如转账、改密等)。CSRF与XSS最大的区别就在于,CSRF并没有盗取cookie而是直接利用

对于初学者而言,找漏洞最好是基于白盒审计进行,所谓白盒审计可以简单地理解为就是看着代码找漏洞,那么在正式挖洞前,我们先看看开源的DVWA给出的四种级别的CSRF的源代码。

0x01 基于dvwa的代码审计

DVWA 的代码分为四种安全级别:Low,Medium,High,Impossible。初学者可以通过比较四种级别的代码,接触到入门级别的代码审计的内容。

白帽子挖洞—跨站请求伪造(CSRF)篇_第1张图片

DWVA使用界面

白帽子挖洞—跨站请求伪造(CSRF)篇_第2张图片

跨站请求伪造(CSRF)

白帽子挖洞—跨站请求伪造(CSRF)篇_第3张图片

在左下角的DVWA Security可以调节难度系数,即low,medium,high,impossible选中后点击submit提交即可。

白帽子挖洞—跨站请求伪造(CSRF)篇_第4张图片

点击左下角view source可以看到源代码,方便进行代码审计

我们可以看到四种级别的代码分别如下所示:

Low级别代码:

白帽子挖洞—跨站请求伪造(CSRF)篇_第5张图片

分析关键代码:

白帽子挖洞—跨站请求伪造(CSRF)篇_第6张图片

可以看到:

服务器只检查参数password_new与password_conf是否相同,如果相同,就可以进行修改密码的操作,整个过程中并没有任何的防CSRF机制(cookie、会话等)

medium级别代码:

白帽子挖洞—跨站请求伪造(CSRF)篇_第7张图片

分析关键代码:

可以看到:

Medium级别的代码引入了eregi函数,Eregi函数的原理是用来检验第二个参数中是否含有第一个参数,并且Eregi不区分大小写,在此处的代码中,该函数起到的作用为检查HTTP_REFERER中是否包含SERVER_NAME,如果包含,则符合条件,继续进行接下来的操作。代码希望通过这种机制来抵御CSRF攻击。

High级别代码:

白帽子挖洞—跨站请求伪造(CSRF)篇_第8张图片

分析:

关键代码:

可以看到:

High级别的带入引入了Anti-CSRF

token,每次修改密码服务器会通过generateSessionToken()随机生成一个token,只有客户端提交的token参数与服务器端一致时,服务器端才会处理客户端的响应。

Impossible代码

白帽子挖洞—跨站请求伪造(CSRF)篇_第9张图片

分析:

关键代码:

可以看到:

Impossible级别的代码在medium、high级别的基础上引入了PDO,同时需要客户端在修改密码时必须正确输入原密码才能进行修改操作。如果不知道原密码,则无法进行CSRF攻击。

0x02挖掘漏洞

注:下文的提到的漏洞均已获授权进行测试,并交由厂商修复。

先来一枚最简单的CSRF的漏洞(很多师傅在挖洞的过程中总是会天马行空地秀很多花样姿势,在这枚漏洞中,本来漏洞本身的危害是非常小的,但是结合蠕虫,就会导致一定的危害)

这次介绍的漏洞就是大部分学校要求大一新生强制安装的XX产品

在XX产品的发送动态处抓包

白帽子挖洞—跨站请求伪造(CSRF)篇_第10张图片

可以看到post包中没有加token,也没有验证refer,可以引发CSRF

开始构造我们的POC

该poc执行会自动发送一条动态,内容为:班上的成绩已经出来了,没想到我会进步这么多。成绩表:http://dwz.cn/1u18Ys

效果如图

白帽子挖洞—跨站请求伪造(CSRF)篇_第11张图片

实际上,当不明真相的吃瓜群众点击链接时,其实就触发了我们构造的POC,此时,群众们的帐号就会不知不觉间发出同样内容的动态。

这样子,就形成了可以广泛传播的蠕虫

总结:这个危害并不是很大,而且早已被修复,该漏洞的难度类似于DVWA中的低级别漏洞

第二枚漏洞:

某网站查看个人已发表的评论处如图:

白帽子挖洞—跨站请求伪造(CSRF)篇_第12张图片

同样,我们还是构造一个POC

Html关键代码如下:

其中,我们使用了标签,地址为删除文章的链接

如果正常用户访问此页面,将会得到如下页面


图片无法访问,不过img中的地址链接还是正常执行了,此时如果用户回到个人中心,会发现,自己发表的东西已被删除

白帽子挖洞—跨站请求伪造(CSRF)篇_第13张图片

总结:这个漏洞涉及的代码层次也是属于DVWA的low级别的

再来枚类似的漏洞,通过这枚漏洞我们可以修改收货地址

此漏洞存在于某音乐播放器的PC端

我们在修改地址的部分抓包

白帽子挖洞—跨站请求伪造(CSRF)篇_第14张图片

注意到此处我们post时没哟token或referer

这就好办了,我们构造一个form表单

白帽子挖洞—跨站请求伪造(CSRF)篇_第15张图片

接下来登陆收货地址的页面


白帽子挖洞—跨站请求伪造(CSRF)篇_第16张图片
白帽子挖洞—跨站请求伪造(CSRF)篇_第17张图片

可以看到我们POC中的内容成功地被修改在了收货地址处

总结:此漏洞的强度也近似于DVWA的low级别


0x03资源推荐

代码审计方面可以使用法师尹毅(Seay)的源代码审计系统

DVWA方面的实际操作可以登陆合天网安实验室进行练习,连接如下:

http://www.hetianlab.com/cour.do?w=1&c=C172.19.104.182015061009315500001

抓包改包看参数的神器burpsuite在合天网安实验也有相应课程,连接如下:

http://www.hetianlab.com/cour.do?w=1&c=C172.19.104.182014112610353900001

0x04经验心得

CSRF漏洞的分类及检测挖掘方法主要有三种:

第一种:

请求直接是个GET请求,然后请求中没有token验证参数,然后还有一个固定的变量可以被控制。这种是比较常见的一种CSRF漏洞。

检测方法:

网页操作某功能,抓包后,如果发现满足上面条件,然后再去页面测试下,基本就可以确定存在不存在CSRF漏洞了。


第二种:

请求是个POST请求,post请求中没有token参数,然后请求也没有验证referer信息。这种是存在CSRF情况最多的一种。

检测方法:

网页操作某功能,抓包后,如果发现没有token等参数,然后就将referer信息设置为空,再次发包请求,如果请求成功了,就说明这里有CSRF漏洞。如果有token等参数,可以尝试将token去掉,然后再将referer也去掉,进行验证。这种CSRF漏洞的利用,是需要在自己服务器构造一个form表单的,然后将服务器form表单的URL作为CSRF攻击进行利用的,或者用js代码生成form表单,或者用ajax实现。


第三种:

请求是POST,post请求中没有token参数,但是验证了referer信息。然而可以将post请求改写为get请求,然后通过第一种情况下的那个方法利用。

检测方法:

就是先执行了第二种的验证后,发现有对CSRF进行防御。然后将post请求改写为GET请求,发现仍然可以成功执行。漏洞成因是因为服务器端接收请求参数的时候,没有严格的用$_POST 而是用的类似于 $_REQUEST这种post,get请求的参数都可以接收的写法。

以上为作者结合自身经验及参考其他师傅的想法总结出来的,欢迎大家留言讨论其他想法、姿势。


0x05防护措施

主要可以应用以下介绍的几种方法:

限制验证cookie的到期时间:

这些cookie的合法时间越短,黑客利用你的Web应用程序的机会就越小。不过,这个时间越短,用户就越不方便。因此,你需要在安全性和方便性之间进行平衡。

执行重要业务之前,要求用户提交额外的信息:

要求用户在进行重要业务前输入口令,这可以防止黑客发动CSRF攻击(只要浏览器中没有包含口令),因为这种重要信息无法预测或轻易获得。

使用秘密的无法预测的验证符号:

当保存在用户浏览器中的cookie仅由一次会话确认时,CSRF攻击才会有效。所以在每次HTTP请求(当然攻击者无法提前知道)中都有附加的特定会话的信息,这样就可以挫败CSRF攻击。不过,如果这种应用程序存在跨站脚本漏洞,黑客就有可能访问这种验证符号。

使用定制的HTTP报头:

如果执行交易的所有请求都使用XMLHttpRequest并附加一个定制的HTTP报头,同时拒绝缺少定制报头的任何请求,就可以用XMLHttpRequest

API来防御CSRF攻击。由于浏览器通常仅准许站点将定制的HTTP报头发送给相同站点,从而了防止由CSRF攻击的源站点所发起的交易。

检查访问源的报头:

在浏览者发送HTTP请求时,它通常会包含源自访问源报头的URL。理论上讲,你可以使用这些信息来阻止源自其它任何站点(而不是来自Web应用程序自身)的请求。不过,访问源报头并不总是可用的,(例如,有些单位由于私密性的缘故而将它剥离了),或者这个报头容易被欺骗,所以说,这条措施并不真正有效。


0x06声明

本系列文章旨在普及网络安全知识,提高小伙伴的安全意识的同时介绍常见漏洞的特征、挖掘技巧等。若读者因此做出危害网络安全的行为后果自负,与合天智汇无关,特此声明。

更多干货关注“合天智汇”微信公众号学习哟!

你可能感兴趣的:(白帽子挖洞—跨站请求伪造(CSRF)篇)