Before proceeding to understand IDOR vulnerability, we need to understand few basic terminologies from Identity & Access Management (IAM) which are critical to identify an user:
- Authentication: Whether the user is allowed to access the system or application.
- Authorization: Whether a genuine user is allowed to access the specific data or functionality within the application.
Let’s take a simple example to showcase the difference between Authentication and Authorization. You may be having a social media account let’s say on Facebook, you are able to login into your account, this is known as Authentication. Once logged into your account, you will be able to access your personal messages but not your friend’s personal messages which is known as Authorization (as you are not allowed to access your Friend’s messages). If Authorization rules were not properly laid upon then you may be able to access your friend’s personal messages.
Insecure Direct Object Reference (IDOR) is a type of vulnerability in which Authorization is violated i.e. an authenticated user is allowed the access to objects such as files, sensitive information etc., which were not allowed by the system administrator to that particular user.
Explanation
Let’s say we have a web application which contains a Login (/login) page to authenticate the user such that they can access their respective profiles. For the sake of simplicity we have created three users:
projectasurasadminalice
projectasuras being having malicious intent log’s into the application using his own credentials, notices that the a numerical number is prefixed at the URL endpoint. At every login instance, this numerical number remains same, therefore projectasuras predicted that this numerical number is a unique identifier corresponding to it’s user account on the web application.
Note
The URL endpoint inference made by
projectasurasis:/secret/id
Then projectasuras tries to enumerate a possible combination of valid user id’s which may have been present in the application. The best option is to use lower user id’s as they may contain system administrator’s secret data.
He tries for user id’s such as: 0, 1, etc. During the enumeration, he encountered that 1 is a valid user id and was able to access the profile of admin user mounted at /secret/1.
Despite the user projectasuras is not allowed to access any other profile, he was able to access profile of user admin, which is admin’s object disclosure to projectasuras leading to a successful IDOR attack.
The above guide serves as the basics of an IDOR attack, a separate blog post provides the internal explanation of How IDOR Works.