When an application allows an attacker, who is an authenticated user, to simply change a parameter value that directly refers to a system object in a request and with that gain access to another object that isn't authorized, then we have an Insecure Direct Object Reference (IDOR). A couple of examples that we have already seen are the Local File Inclusion and Directory Traversal vulnerabilities.
According to OWASP, IDOR is the fourth most critical type of vulnerability in Web applications. These vulnerabilities are usually caused by a deficient access control implementation or the use of a "Security through obscurity" policy—if the user cannot see it, they will not know it exists—which tends to be a very common practice among inexperienced developers.
In this recipe, we will cover the key aspects that should be taken into account when designing access control mechanisms in order to prevent IDOR vulnerabilities.
URL?page="restricted_page"), create an index and process it internally (URL?page=2).Insecure Direct Object References vary on how they are presented in a Web application, from a directory traversal to a reference to a PDF document with sensitive information. But most of them rely on the assumption that a user will never find a way to access something that is not explicitly meant to be accessed by such a user.
To prevent this kind of vulnerability, some proactive work needs to be done in design and development time. The key is to design a reliable authorization mechanism that verifies if the user who is attempting to access some information is really allowed to do it or not.
Mapping the referenced object to indexes to avoid the direct use of the object's name as parameter values (like it happens in LFI) is a first step. It's true that an attacker can also change the index number, as they do with the object's name, but it is also true that having an index-object table in the database makes it easier to add a field indicating the privilege level required to access such a resource than not having any table and accessing resources directly by name.
This index table may include, as said before, a privilege level required to access the said object or, being more restrictive, the owner user's ID. So, it can be only accessed if the requesting user is the owner.
And, finally, input validation is a must in every aspect of Web application security.