Insecure Direct Object Reference (IDOR) Vulnerability
One of the most crucial Vulnerabilities listed in top 10 of OWASP is Insecure Direct Object Reference Vulnerability (IDOR Vulnerability). In this article we will discuss IDOR Vulnerability. Before moving ahead, let us first discuss Authentication. Authentication means to verify the identity of a person and allow that person to access specific requests if the user is authenticated (verified). But if a user is not authenticated and can be able to view files i.e. open files in a wrong way like the Hackers/Attackers do?, it is called Broken Authentication. This article will focus on the way an attacker uses Broken Authentication Vulnerabilities that may lead to IDOR.
What is an IDOR Vulnerability?
In a web application, whenever a user generates, sends or receives a request from a server, there are some HTTP parameters such as “id”, “uid”, “pid” etc that have some unique values which the user has been assigned. An attacker can see such parameter values in cookies, headers, or wifi Packet captures. Via this, an attacker might be able to tamper these values and this tampering may lead to IDOR.
Some of the examples that demonstrate the untrusted data which can be manipulated using IDOR:
Here we can see that the uid in the URL seems to be vulnerable and can be tampered by an attacker to break the authentication.
How IDOR Vulnerabilities get executed?
Let us first discuss the back-end working of a Web application that uses the unauthenticated medium in SQL, which leads to accessing user account information.
String query = "SELECT * FROM accts WHERE account = ?"; PreparedStatement pstmt = connection.prepareStatement(query, ... ); pstmt.setString(1, request.getParameter("acct")); ResultSet results = pstmt.executeQuery( );
In the above code, the attacker will modify the “accts” parameter in the web application and can enter multiple account numbers to retrieve the information.
Steps involved in execution of IDOR attack:
Burp Suite Tool is widely used by attackers to execute such type of Attacks. Following are the steps being followed:
- Capture the Request: First of all, an attacker will decide a target website to which he wants to execute an IDOR attack. Then the website is added to the scope and spider the website to get all the URLs with specific parameters in it.
- Filter the parameters Request: After the first step, we will filter our captured request with the parameter filters. An attacker will only choose that parameter or Injection points where they can execute the attacks.
- Forward request to Repeater: Now, if an attacker will find some of the injection point where they can execute IDOR, they will forward the request to the repeater. The vulnerable URL might look something like this: www.xyz.com/myaccount/uid=19. Here the “UID” seems to be vulnerable.
- Tampering of Parameters: Now as the attacker has the vulnerable injection point, they will now try to execute the IDOR attack with the help of Social engineering or the pattern as written in injection point. Example: an attacker may change uid from 19 to 20 which will open account of another user who has been assigned id number 20.
Impacts of IDOR Vulnerability:
- Exposure of Confidential Information: When the attacker will have control over your account via this vulnerability, it is obvious that an attacker will be able to come across your personal information.
- Authentication Bypass: As the attacker can have access to millions of account with this vulnerability, it will be a type of Authentication bypass mechanism.
- Alteration of Data: An attacker may have privileges to access your data and alter it. By this, an attacker may have permission to make changes to your data, which may lead to manipulation of records.
- Account Takeover: While an attacker may have multiple access to user accounts just by changing the “UID” values, this will lead to account takeover vulnerability. When one vulnerability leads to another vulnerability(like in this case), It is known as Chaining of BUGS.
Remediation of IDOR Vulnerability:
- Developers should avoid displaying private object references such as keys or file names.
- Validation of Parameters should be properly implemented.
- Verification of all the Referenced objects should be done.
- Tokens should be generated in such a way that it should only be mapped to the user and should not be public.