The fourth article of this series is dedicated to Insecure Direct Object References flaws (ranked #4 on the OWASP Top 10)
“Insecure Direct Object Reference”, or Insecure DOR. Behind this strange name stands one type of vulnerability that is quite easy to exploit, and despite quite easy to detect and remediate, very common in web applications.

Let’s have a closer look at its name:

“Object”: By object, you can understand: any resource, file, URL, function or data that can be accessed in a given application. As an example, a photo can be the object.

“Reference”: The reference is the item that designates the object and that the user utilizes to tell the application which object they want to access. For instance, let’s suppose the photo has an identifier like 002546. The end user will access the photo via a URL like http://www.example.com/photos/002546

“Direct”: Direct means that the reference (002546) is making an immediate reference to the photo, which might be named “002546.jpeg” in the server’s files system.

“Insecure”: Well… you understood it, the above URL and the implemented logic behind it have something insecure. As an example, if the application we are dealing with stores private photos, like a social network or a photo albums management system on the web, the insecure aspect could be that anyone can access the private photo, just by typing the URL in a browser. A normal user would for instance change the URL in the browser and try to access http://www.example.com/photos/002547, or http://www.example.com/photos/002548, displaying photos that might not belong to him!

Illustration - espionnage

OK, accessing photos you should not be able to see because you’re not authorized to is bad. Of course, the impact is big, as your application does not securely store photos: anyone can access any photo on the server. But the impact could be really bigger if the the application were manipulating sensitive data (PII data, bank account data, invoices or any other document that is private…).

So, how to prevent such vulnerabilities?
Two different approaches can be adopted (one of the two is sufficient):
– Using per-session or per-user indirect references.
– Checking access rights for direct references.

Using per-session of per-user indirect references

The idea is quite simple: The web application would provide the end user with links/parameters that only make sense inside the current web session.
Going back to the photo example we discussed above, the user would be able to get the photos by using that kind of URL: http://www.example.com/myphotos/36
The same URL would in this case not reference the same photo, depending on the who’s reaching it, making impossible any attempt to access other users’ photos.
Inside the web application, http://www.example.com/myphotos/36 is making reference to a specific photo that doesn’t have “36” as an ID, but maybe ID “002547”. That mapping between the indirect reference and the real photo is invisible to the user.

Checking access rights for direct references

Using indirect references is not always possible. You can also use references that will use random characters making it quite difficult to guess, but in many situations you will have to control who is accessing a given resource. As an example, if your photo application allows for sharing, the URL must be valid for multiple users, but not any user.
In this case, a strong access rights mechanism must be put in place.
The URL to be share might be http://www.example.com/photos/bryan/dga7asg5s0sbaeaa7sba and accessing this URL would trigger a mechanism that checks whether or not you can access the photo.

Other articles in this series: