Question

IDORs happen when an application fails at two things. First, it fails to implement access control based on user identity. Second, it fails to randomize object IDs and instead keeps references to data objects, like a file or a database entry, predictable.

IDOR(IDentify-based Object-level Restriction) 的发生是应用程序在两个方面出现问题时发生的。首先，它未能基于用户身份实现访问控制。其次，它没有随机化对象 ID，而是保持对数据对象（如文件或数据库记录）的引用可预测。

In this chapter’s first example, you were able to see messages belonging to user 1233 because the server didn’t check the logged-in user’s identity before sending private info. The server wasn’t verifying that you were, in fact, user 1233 . It simply returned the information you asked for.

在本章的第一个例子中，您能够看到属于用户 1233 的消息，因为服务器在发送私人信息之前并没有检查已登录用户的身份。服务器没有验证您确实是用户 1233。它只是返回了您请求的信息。

In this case, since user IDs are simply numbers, it’s easy to infer that you can also retrieve the messages for user 1232 and user 1231 , like so:

在这种情况下，由于用户 ID 只是数字，因此可以轻松推断您也可以检索用户 1232 和用户 1231 的消息，如下所示：

1. https://example.com/messages?user_id=1232
2. https://example.com/messages?user_id=1231

This is why the vulnerability is called an insecure direct object reference . The user’s ID is used to directly reference the user’s private messages on this site. If not secured by proper access control, these predictable direct object references expose the data hidden behind them, allowing anyone to grab the information associated with the reference.

这就是为什么漏洞被称为不安全的直接对象引用。用户的 ID 被用来直接引用该站点上的用户私信。如果没有经过正确的访问控制保护，这些可预测的直接对象引用会暴露其后面的数据，允许任何人获取与引用相关联的信息。

Applications can prevent IDORs in two ways. First, the application can check the user’s identity and permissions before granting access to a resource. For example, the application can check if the user’s session cookies correspond to the user_id whose messages the user is requesting.

应用程序可以通过两种方式防止 IDOR。首先，应用程序可以在授予对资源的访问权限之前检查用户的身份和权限。例如，应用程序可以检查用户的会话 cookie 是否与用户请求的消息所对应的用户 ID 相对应。

Second, the website can use a unique, unpredictable key or a hashed identifier to reference each user’s resources. Hashing refers to the one-way process that transforms a value into another string. Hashing IDs with a secure algorithm and a secret key makes it difficult for attackers to guess the hashed ID strings. If example.com structured its requests as follows, attackers would no longer be able to access other users’ messages, since there would be no way for an attacker to guess such a long, random user_key value:

其次，该网站可以使用一个唯一、难以预测的密钥或散列标识符来引用每个用户的资源。哈希是指将一个值转换为另一个字符串的单向过程。使用安全算法和秘密密钥对散列 ID 进行处理，可以使攻击者难以猜测散列的 ID 字符串。如果 example.com 将其请求结构化如下，攻击者将不再能够访问其他用户的消息，因为攻击者无法猜测出这样一个长的、随机的 user_key 值：

https://example.com/messages?user_key=6MT9EalV9F7r9pns0mK1eDAEW

But this method isn’t a complete protection against IDORs. Attackers can still leak user information if they can find a way to steal these URLs or user_keys . The best way to protect against IDORs is fine-grained access control, or a combination of access control and randomization or hashing of IDs.

但是这种方法并不能完全保护用户免受 IDOR 攻击。如果攻击者找到了窃取这些 URL 或用户密钥的方法，他们仍然可以泄露用户信息。防止 IDOR 攻击的最佳方法是精细的访问控制，或者将访问控制与 ID 的随机化或哈希化相结合。