Intro to IDOR

不安全的直接对象引用（IDOR）漏洞是最常见的web漏洞之一，会严重影响易受攻击的web应用程序。当web应用程序暴露对对象（如文件或数据库资源）的直接引用时，就会出现IDOR漏洞，最终用户可以直接控制该对象以获得对其他类似对象的访问权限。如果由于缺乏可靠的访问控制系统，任何用户都可以访问任何资源，则该系统被认为是易受攻击的。 构建一个可靠的访问控制系统非常具有挑战性，这就是IDOR漏洞普遍存在的原因。此外，自动化识别访问控制系统弱点的过程也相当困难，这可能导致这些弱点在进入生产之前一直无法识别。 例如，如果用户请求访问他们最近上传的文件，他们可能会得到一个链接，例如（download.php？file_id=123）。因此，由于链接直接引用了带有（file_id=122）的文件，如果我们试图用（download.php！file_id=124）访问另一个文件（可能不属于我们），会发生什么？如果web应用程序在后端没有适当的访问控制系统，我们可以通过发送带有file_id的请求来访问任何文件。在许多情况下，我们可能会发现id很容易被猜测，从而可以根据我们的权限检索许多我们不应该访问的文件或资源。

What Makes an IDOR Vulnerability

仅仅公开对内部对象或资源的直接引用本身并不是一个漏洞。然而，这可能会使利用另一个漏洞成为可能：弱访问控制系统。许多web应用程序通过限制用户访问可以检索这些资源的页面、函数和API来限制用户访问资源。然而，如果用户以某种方式访问了这些页面（例如，通过共享/猜测的链接），会发生什么？他们仍然能够通过简单的链接访问相同的资源吗？如果web应用程序的后端没有访问控制系统来比较用户的身份验证和资源的访问列表，那么他们可能能够。
有许多方法可以实现用于web应用程序的可靠访问控制系统，例如具有基于角色的访问控制（RBAC）系统。主要结论是，IDOR漏洞的存在主要是由于后端缺乏访问控制。如果用户直接引用了缺乏访问控制的web应用程序中的对象，攻击者就有可能查看或修改其他用户的数据。
许多开发人员忽略了构建访问控制系统；因此，大多数web应用程序和移动应用程序在后端都没有受到保护。在这样的应用程序中，所有用户都可以任意访问后端上的所有其他用户的数据。阻止用户访问其他用户数据的唯一方法是应用程序的前端实现，该应用程序旨在只显示用户的数据。在这种情况下，手动操作HTTP请求可能会显示所有用户都可以完全访问所有数据，从而导致成功的攻击。
所有这些都使IDOR漏洞成为任何web或移动应用程序最关键的漏洞之一，这不仅是因为暴露了直接的对象引用，而且主要是因为缺乏可靠的访问控制系统。即使是一个基本的访问控制系统也很难开发。一个覆盖整个web应用程序而不干扰其功能的全面访问控制系统可能是一项更困难的任务。

practice

Try to read the details of the user with ‘uid=5’. What is their ‘uuid’ value?

image-20230911093346827

抓包后提交的信息稍微多，我们先修改uid，发现返回：

uid mismatch

他似乎把接口与uid相对应起来，我们同时更改接口号为2：

uuid mismatch

正如我们所看到的，这一次，我们收到一条错误消息，说uuid不匹配。web应用程序似乎正在检查我们发送的uuid值是否与用户的uuid匹配。由于我们正在发送自己的uuid，因此我们的请求失败了。这似乎是防止用户更改其他用户详细信息的另一种访问控制形式。 接下来，让我们看看是否可以创建一个向API端点发出POST请求的新用户。我们可以将请求方法更改为POST，将uid更改为新的uid，并将请求发送到新uid的API端点：

image-20230911094045276

尝试将我们的角色更改为admin/administrator以获得更高的权限。不幸的是，在不知道有效角色名称的情况下，我们在HTTP响应中得到无效角色

此时我们发现uid与接口号是相对应的，我们尝试像端口5发送get请求：

image-20230911094538943

拿到uuid

Chaining IDOR Vulnerabilities

通常，对API端点的GET请求应该返回被请求用户的详细信息，因此我们可以尝试调用它来查看是否可以检索用户的详细内容。我们还注意到，页面加载后，它会通过向同一API端点的GET请求获取用户详细信息：

如前一节所述，我们的HTTP请求中唯一的授权形式是role=employee cookie，因为HTTP请求不包含任何其他形式的用户特定授权，例如JWT令牌。即使令牌确实存在，除非后端访问控制系统将其与请求的对象详细信息进行主动比较，否则我们仍然可以检索其他用户的详细信息。

Information Disclosure

Modifying Other Users’ Details

除了允许我们查看潜在的敏感细节外，修改另一个用户的详细信息的能力还使我们能够执行其他几种攻击。一种类型的攻击是修改用户的电子邮件地址，然后请求密码重置链接，该链接将发送到我们指定的电子邮件地址中，从而使我们能够控制他们的帐户。另一种潜在的攻击是在“about”字段中放置XSS有效载荷，一旦用户访问其编辑配置文件页面，就会执行该有效载荷，使我们能够以不同的方式攻击用户。

Chaining Two IDOR Vulnerabilities

由于我们发现了IDOR Information Disclosure漏洞，我们还可以枚举所有用户并查找其他角色，最好是管理员角色。尝试编写一个脚本来枚举所有用户，类似于我们之前所做的操作。 一旦我们枚举了所有用户，我们将找到一个具有以下详细信息的管理员用户：

通过将我们从IDOR information Disclosure漏洞获得的信息与API端点上的IDOR Insecure Function Calls攻击相结合，我们可以修改其他用户的详细信息并创建/删除用户，同时绕过各种访问控制检查。在许多情况下，我们通过IDOR漏洞泄露的信息可以用于其他攻击，如IDOR或XSS，从而导致更复杂的攻击或绕过现有的安全机制。 有了我们的新角色，我们还可以执行批量分配来更改所有用户的特定字段，比如在他们的配置文件中放置XSS有效载荷，或者将他们的电子邮件更改为我们指定的电子邮件。