IDOR attack

IDOR stands for Insecure Direct Object Reference is a security vulnerability in which a user is able to access and make changes to data of any other user present in the system. It has been placed fourth on the list of OWASP Top 10 Web application security risks since 2013. This attack is likely to occur when the internal implementation object, without any validation mechanism which allows attackers to manipulate these references to access unauthorized data.

This attack also reveals the storage patterns/identifiers for the data in the backend and database systems to the attacker, which can be further exploited. Knowledge of storage identifiers allows the attacker to launch an enumeration attack. An enumeration attack can be described as where the attacker builds a collection of valid identifiers using the discovered format/pattern and test them against the application.

Example Attack Scenario

The application below uses an unverified data in a SQL call that is accessing account information:

Now, the attacker can simply modify the ‘acct’ parameter in the browser to send any random account number in the following URL format: http://example.com/app/accountInfo?acct=notmyacct

If no verification checks are employed, the attacker can access any user’s account, instead of only the intended customer’s account. Thus, creating a potential entry point for the attacker into the system.

Preventive Mechanisms

Developers can use the following resources/points as a guide to prevent insecure direct object reference during the development phase itself. The overall objective is to prevent the exposure of real identifier in a simple, portable and stateless way as it is a requirement to handle session and session-less application topologies.

• Developers should use only one user or session for indirect object references. This prevents attackers from directly targeting unauthorized resources.
• It is also recommended to check the access before using a direct object reference from an untrusted source.