Hello and welcome back everyone.
Today let us learn about IDOR, which basically is familiar to anyone. I am just going to tell you how it actually works. I know its a little off-topic for our bug hunting series, but trust me this one is actually a good one to know.
Insecure Direct Object Reference (IDOR) is an access control vulnerability that arises due to the web application granting direct access or reference to internal objects/ resources/ functions of the application which listens to user-side given input without performing any additional authorization or access checks. It is such a vulnerability that can disclose sensitive information that is stored in the web application, thus giving the attacker control over the web application. It is a good example of horizontal privilege escalation, although can also be worked up for vertical privilege escalation.
IDOR in action
Every web application has a database with its customer IDs. For example, let’s take a web application processing request with a URL such as the below one.
So the application is clearly showing us the customer number in the URL, if the web application has no proper control over the user input then the attacker can change the number of the customer to view the details of the other customer. So if the attacker can change the last parameter as number=12356 then he can see all the details of the customer with this ID which he doesn’t have any access to, by simply bypassing. If he can actually replace the number with number=1 then he can see the details of the administrator account, which eventually leads to escalation of your privileges. This is an example of an IDOR vulnerability that leads to horizontal privilege escalation. The same can be done with static files too that are inside the web application.
This IDOR when chained with other attacks as mentioned below can cause serious damage to the web application
 — Directory Traversal Vulnerability
 — File Upload Vulnerability
 — File Inclusion Vulnerability
Let’s learn about each of them in detail.
Directory Traversal Vulnerability
It is a vulnerability in which the hacker gets his hand into a webroot directory of the application and travels from there to the other directories by horizontal traversal in search of sensitive information.
Let us assume that there is a file in the application which is vulnerable to IDOR. So first the attacker gets into this directory and from there they start their search for sensitive information such as /etc/passwd or /etc/shadow which basically contains user names and user passwords(hashes) respectively. Once the attacker gets into that sensitive directory which they don’t have any permission to, an attacker can now use this information to get into other’s accounts without their consent.
The above example has IDOR vulnerability in file.php. So from there, he traveled in search of /etc/passwd just by adding ../ till he found the file in the web application.
The hacker can also go in search of files that are not authorized for users to see. By using this directory traversal he/she can actually be able to see the files in that web application.
In the above example, there is a file named names.txt. So if there is vulnerability he can replace that filename with something another and can access that file in a web application if it is present.
File Upload Vulnerability
It is another vulnerability that can lead to IDOR, in which the attacker gains access to the web application by uploading malicious files into it. This happens when the application doesn’t perform proper checks of the file that the user is uploading.
For example, let us take a website that allows users to upload files. When uploading a file the developer has to make sure that the application checks whether the file being uploaded is actually a safe file or not. It has to perform two checks about the file.
First, the developer should make sure that the user cannot upload the files that are not in the list of safe extensions or needed extensions (Like if the application is asking for a photo to be uploaded it should allow only those extensions of photos like .png or .jpg or .jpeg it should not accept .txt files or others).
The second check is on the content inside the file, what is the actual content that is being uploaded. The application should make sure that the content inside the file is as shown in the extension of the file (The application should not allow a file with a .png extension with some random text in it).
The developer should make sure that the application is blocking the files that don’t meet these requirements.
File Inclusion Vulnerability
It is a type of web application vulnerability that works in the run-time by listening to the user-side instructions rather than server-side instructions. There are two types of File Inclusion Vulnerabilities
· Remote File Inclusion
· Local File Inclusion
Remote File Inclusion (RFI) happens if the attacker can upload and execute files from his own webserver to the application’s web server. Once the file is executed in the web application then the attacker can perform his actions to get sensitive information by path traversal we learned earlier, can get access logs of visitors, also can see or even manipulate files inside the application.
Local File Inclusion (LFI) allows an attacker to get access to a web application using the scripts already present in it. After successfully uploading files using RFI, the attacker can run those scripts containing malicious code and thus can get access to the web application. This can also be done without uploading files or scripts if we know what files are present in it, like /etc/passwd path we learned earlier. Here the attacker is actually using directory traversal to disclose sensitive information. But to successfully gaining access to the app using this technique is difficult if both the scripts and web application are not running on the same server.
What IDOR can do
· It can help attackers obtain unauthorized data access to web applications.
· It allows the attacker to perform unauthorized operations.
· It can allow the attacker to manipulate application objects.
· It gives direct access to files in web applications.
· The attacker can even take down the server.
Preventing IDOR
· Making web applications not to trust user side input.
· Ensuring user is uploading non-malicious content.
· Using indirect object references.
· Using secure hashes instead of original objects.
IDOR is not seen in many web applications but if it is present it can cause serious damage to the application.
That’s all from my side today and catch you up again in the next post with another vulnerability. I would love to hear your feedback and improve myself. Check out my Instagram to get more updates and tricks.
Till then take care and Happy Hacking!!!👋👋
