挖洞经验分享:关于IDOR的几个奇怪案例分析

2020-04-04 88450人围观 漏洞网络安全

果阿这个地方一直是冒险者的天堂,就在前不久,我们几个朋友计划去果阿旅行,于是乎我们便在Skyscanner上搜索廉价机票,然后找到了一个名为“whereIDORsLive.com”的网站。这个网站的优惠幅度非常大,它是一个大型旅游门户网站。在这篇文章中,我将跟大家分享几个我从中发现的IDOR(不安全的直接对象引用)漏洞。

第一个IDOR:下载任意用户的机票

当我在该网站的交易确认页面中继续完成机票订购时,我发现了一个选项,即将机票订单的PDF版通过短信、右键和直接下载的方式提供给用户。

于是,我直接下载了机票的PDF文件。PDF文件名是一个加密字符串,我一开始以为它使用的是Base64编码,但解码之后却生成了一堆乱七八糟的东西。这种情况很常见,即字符串经过加密之后再次被编码为Base64格式,这样它们就可以转换为可打印的字符,以便在应用程序之间进行平滑传输和呈现。

每当我在网站中看到有数据被加密时,我都忍不住想要去研究一下,因为根据我的经验,大多数网站在使用加密算法时都存在错误实现或者错误的“自定义”实现。

我之所以觉得这个网站有问题,是因为他们没有为他们的API使用SSL证书,并且对PDF文件名进行了加密操作,这里一定有问题。于是乎,我右键点击了网页上的“下载PDF”按钮,然后审查元素。

我们发现,代码使用我的“订单ID”作为参数调用了downloadPdf函数。那么我所做的第一件事,就是将我的订单ID+1,比如说“66786694”,然后再次调用该函数。但此时打开的仍然是我这一份订单PDF,无论你提供给downloadPdf函数的订单ID值是多少,它都只会返回当前机票订单的PDF。接下来,我开始分析downloadPdf函数。

函数代码很简单,它接收一个订单ID号作为参数“tid”(这里就是“66786693”),但是却没有将其重新分配给加密字符串“hdnBookingId”。因此,当你单击它时,将会在一个新的选项卡中打开你的PDF:

http://api.whereIDORsLive.com/XYZService/EticketPdf/hdnBookingId.pdf

downloadPdf.js【源代码

function downloadPdf(tid) {

    if (document.getElementById("hdnBookingId") != null && document.getElementById("hdnBookingId").value != "")

        tid = document.getElementById("hdnBookingId").value;

    if (tid != null && tid != "" && tid != undefined)

        window.open("http://api.whereIDORsLive.com/XYZService/EticketPdf/" + tid + ".pdf", '_blank');

}

这就很奇怪了,为什么会有人这么做?为什么不直接调用downloadPdf函数?为什么不用它来传递订单编号?我的第一反应,就是遗留代码,此前可能是这个函数直接将“订单ID”转换为URL。因此,我猜测之前的链接形式可能为:

http://api.whereIDORsLive.com/XYZService/EticketPdf/bookingId.pdf

为了查看后端是否仍然有效,我访问了下面这个链接:

http://api.whereIDORsLive.com/XYZService/EticketPdf/66786693.pdf

没错,这条链接给我们返回了PDF,通过枚举订单ID,我还能够获取到其他人的机票订单。

漏洞成因

很可能是因为,后端文件仍然是以“bookingId.pdf”的形式存储的,并且有一个中间件来负责将hdnBookingId解密为bookingId,或者说同时存储了一个订单的两种文件名称/格式,即同时存在“hdnBookingId.pdf”和“bookingId.pdf”。

第二个IDOR:同一家公司的另一个终端节点

接下来,我对该公司旗下的Android应用程序进行了分析,并且发现流量会被路由至一个终端节点处:

http://cloud.whereIDORsLive.in/XYZService/dboperation.svc

这对于黑客来说,绝对是一个宝藏。这是一个记录了所有节点的文档,当点击相应节点的超链接时,还会提供响应的JSON和XML样本Payload,以及节点返回的响应数据格式。检查完这些节点之后,我发现了一个可能会导致某些信息泄露的节点:

/GetETicket/{TransactionscreenID}/{UserName}/{Password}/{ProcessType}

这里要求提供TransactionscreenID、UserName和Password这三个参数,但此时的我竟然有些束手无策测。

通过Android应用程序获取到订票信息后,便会触发这个节点,然后我们就可以查看到获取订票细节所需的参数值了:

节点会以HTML Table的格式返回乘客的信息,而不是之前的PDF格式:

现在,我们可以再看看之前的文档了。还记得ProcessType参数吗?我们可以直接将URL地址中的最后一个参数改成1或者其他值:

将“3”传递给ProcessType参数,将会触发异常,并允许我们查看到底层代码。

第三个IDOR:同一家公司的另一个终端节点

在查看文档时,我还发现了另一个可能会泄露敏感信息的节点:

/GetPaxBookingDetails/{TransactionscreenID}/{UserName}/{Password}

向这个节点请求数据,将会返回用户的个人身份识别信息PII。只要你在这家公司的网站上订过票,那你的数据就可以通过这样的方式来获取到。

漏洞成因

该节点之所以会存在这个漏洞,是因为它没有部署任何的访问控制策略或健壮的身份验证机制。

* 参考来源:medium,FB小编Alpha_h4ck编译,转载请注明来自FreeBuf.COM

相关推荐
取消
Loading...

特别推荐

填写个人信息

姓名
电话
邮箱
公司
行业
职位
css.php