引言

随着Web应用的复杂性不断增加，安全问题也日益突出。不安全的直接对象引用（IDOR）是一种常见的安全漏洞，攻击者可以利用这种漏洞来访问或篡改他们不应该有权访问的数据。本文通过一个实际案例来展示如何发现并利用IDOR和业务逻辑漏洞，以便更好地理解这类安全威胁及其解决方案。

关于目标

目标服务旨在为用户提供一种通过基于 Web 的仪表板来构建服务器端应用程序的方式。每个应用程序归属于一个唯一的账户，并且账户之间应保持完全隔离。

创建应用程序时，需要指定一个标题和 URL。每个应用程序在创建时会被自动分配一个公开的 UUID，这是为了在前端界面中能够明确地引用它。

账户具有以下功能：

1、创建新的应用程序；

2、更新已拥有应用程序的标题和 URL；

3、永久性删除已拥有应用程序（请注意，这一操作无法撤销）。

访问控制

我迅速发现了几个低至中等严重性的漏洞，并立即报告了这些问题。实际上，并没有什么特别值得一提的事情。

由于界面显得非常整洁，整个系统看起来制作精良，我不确定还能否找到更严重的漏洞。于是，我决定将注意力转向访问控制方面。也许之前我忽略了某些不安全的直接对象引用 (IDOR) ...

准备IDOR狩猎

对于 Web 应用程序的安全测试，我通常使用 Firefox 进行应用测试，并通过 Burp Suite 代理所有相关流量。最近，为了测试访问控制，我还加入了 Firefox 的多账户容器这一工具。这个 Firefox 插件就像是加强版的隐私浏览窗口：它让你能够轻松切换不同的会话，而无需反复登出一个用户再登录另一个用户。这个工具大大减轻了手动寻找不安全的直接对象引用 (IDOR) 的枯燥工作，我真希望早点就了解到它。想要了解 Firefox 多账户容器的优秀介绍，可以观看 Katie 的相关视频（感谢 Katie！）。

像许多其他安全研究人员一样，如果可能的话，我通常会创建至少两个虚拟账户。这样，我可以安全地检查当作为另一个账户登录时，尝试操作一个账户拥有的资源是否会带来影响，同时避免干扰系统中合法用户的资源。

这次也不例外：我创建了两个虚拟账户，它们分别被分配了 ID 101 和 102。我决定让账户 101 扮演攻击者的角色，而账户 102 则是受害者。

随后，我在每个账户下创建了一个应用，并为了简化这篇文章，分配了以下 UUID：

10110110-1101-1011-0110-110110110110（由账户101，即攻击者拥有）

10210210-2102-1021-0210-210210210210（由账户102，即受害者拥有）

URL中顺序账户ID，但未发现IDOR

在我代理的历史记录中，我发现每当查看攻击者账户下的应用时，都会发出以下请求：

立刻引起我兴趣的是：账户使用连续整数作为标识符。对攻击者而言，公开使用连续整数标识的资源总是很有吸引力。由于连续ID易于枚举，至少可以用来揭示组织可能未意识到的更多信息：外部观察者确实可以通过监控新ID的发放速度来衡量系统的使用频率，并据此推断业务状况。

更重要的是，发现使用连续ID的易受攻击注入点是很常见的。因此，我最初尝试在作为攻击者登录时访问受害者账户拥有的应用资源：

但响应正如一个安全系统应有的那样：