介绍

IDOR 漏洞又称 不安全的直接对象引用，是一种访问控制漏洞,当服务器对于用户提供的数据 (文件、数据、文档)进行过滤时，如果过滤不严谨就会产生此漏洞

关键点

  • 密码重置 , 密码修改, 账户恢复
  • 应用程序中敏感信息功能: 消息处理, 私人通话内容等等

利用

修改编码或 hash ID

  • 当我们的目标使用基于编码的 ID 时,我们可以尝试修改这个编码来查看是否形成 IDOR 漏洞.
  • 如果应用程序使用的是一个 hash ID , 我们可以对这个 ID 进行分析,来观察其是否可以被预测,这时候我们可以多创建几个用户来分析其 ID
  • 此外我们还可以通过另一个 API 断点, 应用程序中的其他公共页面（其他用户的个人资料页面等）或通过 referer 在 URL 中泄露随机或散列 ID

例如，一旦我找到一个 API 端点，它允许用户通过哈希对话 ID 检索详细的直接消息。请求有点像这样：

  1. GET /api_v1/messages?conversation_id=SOME_RANDOM_ID

乍一看这似乎没问题，因为conversation_id是一个长的、随机的字母数字序列。但是你实际上可以通过使用他们的用户 ID 来找到每个用户的对话列表！

  1. GET /api_v1/messages?user_id=ANOTHER_USERS_ID

这将返回属于该用户的conversation_ids列表。userid在每个用户的个人资料页面上都是公开的。_因此，您可以阅读任何用户的消息，方法是首先在他们的个人资料页面上获取他们的 user_id，然后检索属于该用户的 conversation_ids 列表，最后通过 API 端点 /api_v1/messages 加载消息！

为应用程序提供一个 ID,即使不要求它

如果应用程序生成的请求中没有使用 ID，请尝试将其添加到请求中。尝试附加id、user_id、message_id或其他对象引用参数，看看它是否对应用程序的行为产生影响。

  1. GET /api_v1/messages

这个如何？它会显示另一个用户的消息吗？

  1. GET /api_v1/messages?user_id=ANOTHER_USERS_ID

HPP (HTTP 参数污染)

HPP 漏洞（为同一参数提供多个值）也可能导致 IDOR。应用程序可能不会预料到用户会为同一参数提交多个值，这样一来，您可能能够绕过端点上规定的访问控制。

原始请求: 

  1. GET /api_v1/messages?user_id=ANOTHER_USERS_ID

但是我们可以魔改此请求:

  1. GET /api_v1/messages?user_id=YOUR_USER_ID&user_id=ANOTHER_USERS_ID
  2. GET /api_v1/messages?user_id=ANOTHER_USERS_ID&user_id=YOUR_USER_ID
  3. GET /api_v1/messages?user_ids[]=YOUR_USER_ID&user_ids[]=ANOTHER_USERS_ID

直接引用数据库对象的 IDOR 漏洞

考虑一个网站，它使用以下 URL 通过从后端数据库检索信息来访问客户帐户页面：

  1. https://insecure-website.com/customer_account?customer_number=132355

在这里，客户编号直接用作对后端数据库执行的查询中的记录索引。如果没有其他控制，攻击者可以简单地修改customer_number值，绕过访问控制来查看其他客户的记录。这是导致水平权限提升的 IDOR 漏洞示例。

攻击者可能能够通过将用户更改为具有额外权限的用户同时绕过访问控制来执行水平和垂直权限提升。其他可能性包括利用密码泄漏或修改参数，例如，一旦攻击者登陆用户的帐户页面。

直接引用静态文件的 IDOR 漏洞

当敏感资源位于服务器端文件系统的静态文件中时，通常会出现 IDOR 漏洞。例如，网站可能会使用递增的文件名将聊天消息记录保存到磁盘，并允许用户通过访问如下 URL 来检索这些记录：

  1. https://insecure-website.com/static/12144.txt

在这种情况下，攻击者可以简单地修改文件名来检索另一个用户创建的副本，并可能获取用户凭据和其他敏感数据。

修改请求方法

如果一种请求方法不起作用，您可以尝试其他许多方法：GET、POST、PUT、DELETE、PATCH……

一个常见的有效技巧是用 POST 代替 PUT，反之亦然：可能没有实现相同的访问控制！