In this post, we covered insecure direct object reference vulnerability which is one of the top 10 on the list of OWASP.
By definition, IDOR or Insecure Direct Object Reference (called IDOR from here) occurs when an application exposes a reference to an internal implementation object. Using this way, it reveals the real identifier and format/pattern used of the element in the storage backend side. The most common example of it (although is not limited to this one) is a record identifier in a storage system (database, filesystem and so on).
How I Exploited It
In my demonstration, I showed how you can spot and exploit an IDOR vulnerability. Here’s how I did it:
- Finding the Vulnerable Object: I started by inspecting the element of a file on the web page. This helped me identify the object that was being used to view the file.
- Manipulating the URL: Once I knew what to look for, I was able to change the URL to trick the “view” function into doing things it wasn’t supposed to do.
- Stealing Cookies: I was able to inject a script into the URL that allowed me to steal the user’s cookies. This is a serious issue because cookies can contain sensitive information, like session IDs, that could allow an attacker to hijack a user’s account.
- Accessing System Files: To take things a step further, I showed how you can manipulate the view object to access sensitive system files, like the password file. This is a classic example of how an IDOR vulnerability can lead to a full system compromise.
How to Protect Yourself
The good news is that IDOR vulnerabilities are preventable. The key is to implement proper authentication and authorization checks for every single object and function on your web server. This means that you need to make sure that users can only access the files and resources that they are explicitly authorized to see.
