用户
搜索
  • TA的每日心情
    开心
    2020-9-1 17:16
  • 签到天数: 18 天

    连续签到: 2 天

    [LV.4]经常看看II

    i春秋-脚本小子

    Rank: 2

    7

    主题

    11

    帖子

    267

    魔法币
    收听
    0
    粉丝
    0
    注册时间
    2015-11-20
    发表于 2020-8-31 16:42:03 14281
    本帖最后由 天堂陨落x 于 2020-8-31 17:00 编辑

    思路分享:测试越权时如何利用好MongoDB Objetc ID

    0x01. 译文声明

    本文是翻译文章,原作者 Amey Anekar
    原文地址:https://techkranti.com/idor-through-mongodb-object-ids-prediction/
    译文仅作参考,具体内容表达请见原文

    0x02. 前言

    有关越权(IDOR)的基础资料可见此:

    越权是渗透测试基操之一,因其:

    • 测试成本低
    • 测试时间短

    从系统开发层面来看,研发人员喜欢在数据表中插入一个自动递增的整型字段作为资源标识符。这种数据库设计模式降低了越权漏洞的测试难度。随着MongoDB数据库使用场景的增多,有些研发人员开始使用该数据库自带的Mongo Object ID作为数据库中的资源标识符(可以理解为一种主键生成策略)。官方说明可见此。该标识符是不完全随机的。

    0x03. Mongo Object ID知识回顾

    Mongo Object ID是12字节的BSON类型数据。从字符长度来看,它们由24个16进制数字组成。这12个字节24个字符是不完全随机的。其格式如下:

    举个栗子,测试时遇到一个资源标识符5f2459ac9fa6dc2500314019,其可分解如下:

    • 5f2459ac:16进制转10进制后得到时间戳1596217772
    • 9fa6dc:机器标识符
    • 2500:MongoDB进程ID
    • 314019:自增计数器

    上述元素中,对于机器标识符,只要运行数据库所在的物理机/虚拟机不变,该值就不变。对于进程ID,只有当MongoDB进程重启时,其值才会改变。然后时间戳,每秒更新一次。

    通过递增计数器时间戳来预测Mongo Object ID的唯一难点就是,MongoDB是在系统级别(如JDBC驱动)生成并返回Mongo Object ID,并且Mongo Object ID不会基于数据表层面来累加。
    举两个例子,在相同业务功能下:

    • 短期内仅由Web应用层面与数据库层面进行交互
      在该场景下,假设一秒内有两个不同的用户发起了注册请求,如果这段时间内刚好只有这两个用户通过应用程序对数据库发起了写入请求,那么他们被分配到的Mongo Object ID可能只在末尾部分的自增计数器上相差1。
    • 短期内数据库与系统上其它程序多次交互
      MongoDB数据库每秒是可以生成上千个Mongo Object ID的,基于上面的前提,如果一秒内有两个用户发起注册请求的同时,系统上有其它程序也在频繁调用(比如写入数据,这个过程会大量消耗掉Mongo Object ID中的自增计数器),那么这两个用户被分配到的Mogon Object ID可能相差十万八千里。

    尽管这些底层交互无法入手判断,但仍可基于有效的Mongo Object ID来在一定维度上进行预测。然后测试时一旦拿到额外有效的资源标识,就可通过此思路再逐步类推,来扩大战果。

    0x04. 一个轮子

    分享一个由Andresriancho师傅编写的Mongo Object ID预测工具
    默认配置下该工具可基于一个给定的Mongo Object ID来预测并返回1000个可能有效的资源标识符。使用截图如下:

    根据生成结果拿到有效字典后,就可以直接用Burp Intruder来测试越权了。

    emmmm,翻译的还可以吧……
    使用道具 举报 回复
    发新帖
    您需要登录后才可以回帖 登录 | 立即注册