tl;dr: I’m Pentester and recently I got my first pentest project and I’ve successfully executed with my senior colleague. As the application was developed to perform the financial operations, I had focus of finding Insecure Direct Object Reference Vulnerabilities. This blog will help you for having the understanding of the IDOR vulnerability.
Insecure Direct Object References (IDOR) occurs when an application provides direct access to the object based on the user-supplied input. As a result of this vulnerability, attackers can bypass authorization and access resources in the system directly, for example, database records or files. Insecure Direct Object References allow attackers to bypass authorization and access resources directly by modifying the value of a parameter used to direct an object. Such resources can be database entries belonging to other users, files in the system, and more. This is caused by the fact the application takes user-supplied input and uses it to retrieve an object without performing sufficient authorization checks.
Type of IDOR:
Threat Agents:
Any user who has partial access to specific types of data on the system.
Attackers approach:
The attacker is an authenticated system user who tries to access the data he isn’t authorized to use or view by simply changing the parameter value that directly references a system object to another object.
Weakness in Security:
The inability of the application to verify the authorization of a user to a target object results in an insecure direct of object reference flaw.
Detection:
Pentesters can identify such flaws and do code analysis to check whether authorization is verified.
Technical Impact:
All the data that is referenced by the parameter is at risk and is compromised.
Business Impact:
Risk of public exposure of the data that is breached by the IDOR Parameter.
How to Discover an IDOR?
The best way to find out if an application is vulnerable to insecure direct object references is to verify that all object references have appropriate defenses.
To achieve this, consider:
- For direct references to restricted resources, the application needs to verify the user is authorized to access the exact resource they have requested.
- If the reference is an indirect reference, the mapping to the direct reference must be limited to values authorized for the current user.
Code review of the application can quickly verify whether either approach is implemented safely. Testing is also effective for identifying direct object references and whether they are safe. Automated tools typically do not look for such flaws because they cannot recognize what requires protection or what is safe or unsafe.
Ensuring IDOR prevention:
- It is also often recommended to use something less obvious that is harder to enumerate as a reference. E.g. a random string instead of an incrementing integer. This can be a good idea for multiple reasons, but should absolutely not be trusted as the only prevention against such an attack.
- Using an indirect object references map:
An indirect reference map is simply a substitution of the internal reference with an alternate ID which can be safely exposed externally. Firstly, a map is created on the server between the actual key and the substitution. Next, the key is translated to its substitution before being exposed to the UI. Finally, after the substituted key is returned to the server, it’s translated back to the original before the data is retrieved.
Example:
Consider the Following code:
Here, what the attacker does is he modifies the “act” parameter in the browser with the value of the target account number that he wants.
Virtual Lab setup on Local Host:
The lab demonstrates a website with a login ID and Password which allows a user to log into his allocated profile.
Consider logging in with Login Credentials for Account –Vinit Patil, email: [email protected] and password: 12345678. This gives us an entry to the user account. Now to view the profile details there is a hyperlink which redirects you to the details page.
Now look closely in the highlighted URL where id=1.Let’s go ahead with modifying the ID=1 with a different value.
By modifying the ID from 1 to 4 we are able to know that there are 4 users that are present on the website while “ID=5” pops out a user not found error.
The above lab helps us identify IDOR vulnerability where the target site has low authentication mechanism which allows the attacker who is also a legitimate user to access direct object reference to view other user’s accounts via the URL.
Recommendations:
It is important to check the authorization privileges of each user and access control checks to restrict references from unknown sources. Also, implement the use of cookie-based authentication to access a classified database.
References:
https://www.owasp.org/index.php/Top_10_2010-A4-Insecure_Direct_Object_References
