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.
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.
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:
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.
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.
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