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.
- The use of indirect references is preferred over the direct ones. For example, instead of referencing a page by name in the parameter (
URL?page="restricted_page"), create an index and process it internally (URL?page=2). - Map the indirect references on a per-user (per-session) basis, so the user only has access to authorized objects even when changing the index number.
- Validate any reference before delivering the corresponding object; if the asking user is not authorized to access it, display a generic error page.
- Input validation is important too, especially in Directory Traversal and File Inclusion cases.
- Never take a "Security through obscurity" posture. If there is some file which contains restricted information, even if it is unreferenced, somebody will find it some time.
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.