破坏的对象级授权

---

什么是破坏的对象级授权？

破坏的对象级授权 (BOLA) 也称为不安全的直接对象引用 (IDOR)。此问题发生在服务器未正确验证当前授权用户或未授权用户是否正在访问数据以读取、更新或删除他们无权访问的对象时。

破坏的对象级授权 (BOLA) 类型

主要有两种类型的 BOLA。如果将用户 ID 或对象 ID 传递给服务器，则可以执行这些操作，我们将研究这两种情况。

基于用户 ID

如果用户 ID 以清晰可见的方式（例如在 URL 或请求中）传递给服务器，例如，当我们请求访问特定用户的全部资源时：

<https://google.com/get_users_search_history?userID=1234>

查看上面的 URL 后，如果我们将用户 ID 更改为其他用户的用户 ID，则我们无权获取其他用户的搜索历史记录，但如果端点容易受到破坏的对象级授权问题的影响，则我们可以查看其他用户的搜索历史记录。

基于对象 ID

此类型的漏洞也可能存在，因为对象 ID 在服务器未正确验证用户是否有权访问该对象时会传递给服务器。例如，当开发人员需要实现安全功能来保护某些资源而又不保护某些资源时。他们可能会避免或忘记保护某些应该受到保护的对象。

利用破坏的对象级访问漏洞

一旦发现此漏洞，就很容易利用它。攻击者只需修改请求中的标识符，他们就可以被授权访问他们不应该被允许访问的对象。

让我们用一个例子来讨论一下。

在这里，我们有一个用于调用 API 的 URL：

https://myemail.com/messages/12345

此 API 调用用于获取用户的私人消息。正在使用的资源是消息。消息是我们指的破坏的对象级授权的对象，我们假设消息只能由预期接收者访问和读取。

在 API 调用中，我们有消息的 ID **12345**。对于攻击者来说，这是一个重要的参数。该 ID 告诉服务要返回哪个记录。API 从数据存储中提取该记录并在响应中返回它。

现在让我们看看如果我们将 ID 从 **12345** 更改为 **12346** 会发生什么？

**示例**：

https://myemail.com/messages/12346

如果 ID 为 12346 的消息是为我们的用户准备的，我们应该能够获取它。但如果该消息属于其他用户，则 API 永远不应该返回它。如果我们设法检索到该消息，那么我们就发生了破坏级别对象授权故障。

另一个例子是传递 POST 请求来更新资源。我们可以在 JSON 负载中使用 ID：

{
   "userId": "12345678",
   "oldPassword": "My_0ld_Pa$$",
   "newPassword": "$uperS3CurE"
}

如果我们能够在请求中放入任何 userId 并能够更新其他用户信息，那么我们就会遇到一个大问题。

技术影响

一旦我们找到漏洞，就可以通过不同的方式利用它。我们可以在 API 上使用不同的 HTTP 方法。我们可以使用该输入参数或 ID 来更新甚至删除消息！

如果我们能够破坏所有 ID 并能够删除所有存储的消息会发生什么？这是一个很大的影响。