挖洞经验 | 如何发现更多的越权漏洞（1）

我非常喜欢搞IDOR漏洞，它通常被称为不安全的直接对象引用或是越权，一般来说它的发现手段相对简单，利用方式也不太难，但是对网站业务的危害影响却比较严重。

就我来说，我此前发现的一些高危漏洞大部份都属于IDOR漏洞范畴之内。

今天我们就来谈谈如何发现更多的IDOR漏洞。

IDOR漏洞介绍

IDOR，Insecure Direct Object reference，即"不安全的直接对象引用"，场景为基于用户提供的输入对象进行访问时，未进行权限验证。

IDOR漏洞其实在越权（Broken Access Control）漏洞的范畴之内，也可以说是逻辑漏洞，或是访问控制漏洞，国内通常被称为越权漏洞。

具体可参考（https://medium.com/@vickieli/intro-to-idor-9048453a3e5d）。

然而，IDOR漏洞并不像增减和切换数字ID号那样简单，

随着应用程序的功能变得越来越复杂，它们引用资源的方式也形式多样

这也意味着简单的数字形式的IDOR漏洞在大多数网络应用中变得越来越少。

IDOR在Web应用中会以不同的方式体现出来，除了通常的简单数字ID号之外

这里我们再来讨论几个值得注意的点。

去意想不到的地方寻找IDOR漏洞

别忘了编码或是哈希过的ID号

当我们面对的是一个编码ID时，总有可能用某种方法来把这个编码ID进行解码。

如果Web应用使用的是哈希或随机的ID编码，此时我们就要看看这个ID是否是可猜测的。

有时Web应用使用的是一些不充分信息熵的算法（algorithms that produce insufficient entropy），其实经过仔细分析后，我们是可以去预测ID号的。

比如，我们可以注册几个账户去分析这种ID号的具体生成模式，然后就得总结得到其它用户ID号的生成方法。

另外，也可以通过其它的API接口中来窥探一些泄露的随机或编码ID，比如Web应用的一些公开页面，如用户资料信息页面、referer链接等。比如，如果我找到一个API接口，它的功能是允许用户通过一个编码会话ID获取到属于自己的一些详细私信内容，其请求格式如下：

GET /api_v1/messages?conversation_id=SOME_RANDOM_ID

乍一看，其中的的会话ID（conversation_id）非常长，而且是随机的字母数字组合序列

但是之后我发现，可以使用用户ID号去获取属于每个用户对应的一个会话列表！如下所示：

GET /api_v1/messages?user_id=ANOTHER_USERS_ID

而在这个会话列表中就包含了属于用户的会话ID号（conversation_id）又因为用户ID（user_id）可以在每个用户的资料页面中公开找到

因此，组合利用这两个ID号，我就能通过接口/api_v1/messages去读取任意用户和私信会话内容了！