- Let's Connect!
- Email: support@securityboat.net
- Phone: +91 9175154999
Insecure Direct Object Reference (IDOR) was listed in the OWASP (Open Web Application Security Project) Top 10 back in 2007 and currently falls under the A5 Broken Access Control category. Idor has been part of the Top 10 vulnerabilities throughout the decade. In Insecure direct object reference an unauthorized request is being made to access or modify objects beyond the end user’s scope.
Let us get started with some basics,
Idor Introduction
Insecure Direct Object References (IDOR) occur when an application grants direct access to objects based on the user’s input. Because of this vulnerability, attackers can bypass authorization and access resources in the system directly, such as database records or files. By modifying a parameter used to directly point to an object using an insecure Direct Object Reference, an attacker can bypass authorization and gain access to resources directly. Using the Human eye to detect and observe from where the request is being made and how it functions in the web application certainly makes it more likely to find these vulnerabilities.
How Idor Works?
In most cases web applications expose the user_ids or user_keys in the request or response, this enables the attacker to access or modify the data present for a specific end user.
To understand this thoroughly,
https://vulnrable-website.com/update_profile?id=99 is the request made by the web application to update profile of end user 99. The update in URL specifies the function and parameter “id” is responsible for detecting valid and authenticated user account. What if we change this request from
https://vulnrable-website.com/update_profile?id=99 to
https://vulnrable-website.com/update_profile?id=100This exposes the unauthorized data to the attacker and carries out unethical actions if the parameter “id” is used with direct object references. Here web server and application are completely dependent upon the user input which is used directly to refer to the objects head on. This was simple demonstartion to understand IDOR better.
Let us see how to detect IDORs in the wild!!
Detecting IDORs (Insecure Direct Object References)
IDORs are hard to prevent since automatic vulnerability scanners fail to detect them. To spot an insecure object reference, you need to have a general understanding of the functioning of an application or website, requests and responses or the information that they should reveal in case of Api as well as web applications. Here are some methods to detect Idor.
Exposer identifiers uniquely representing a set of data in the application results in unauthorized actions from unethical sources. The ids directly represent the access structure by which an attacker can detect the possibility of vulnerability in a web application. Various parameters are applied for uses depending on the web application. Determining the vulnerable parameter can only be achieved by inspecting parameters with their functioning. A parameter may represent a section of a user profile, picture, comment, permissions, or department of a personal account.
2. Source code Review
Instances where direct object reference is applied can be determined through source code review which will enhance chances of detecting a direct reference point. As idor is difficult to determine from automated methods, source code review not only helps attackers but also developers to determine where the direct references to internal resources are mapped.
This includes,
Consider an example of
<ul class="Idor Example"></ul>
<h2 class="charset">Welcome! </h2>
<div id="menu"></div>
<ul class="Idor detection"></ul>
<div id="posts">
<div id="post_1" class="post clearfix">
::before
<a class="post-archive" name="post-3587"></a>
<div class="pull-left"></div>
<div class="pull-right"></div>The “post-3587” contains numeric valued parameter. In this manner IDs can be detected in source code as well.
3. Manual Testing with various accounts.
Interchanging the ids from more than one account leads not only to deep understanding of the web application but also allows you to create scenarios to exploit Idor. Using multiple accounts, it is possible to detect idors and parameters which may be vulnerable to these kinds of exploitation. The more you observe request parameters, the more the chance of finding user_ids and file_ids allowing attacker to exploit web application. You can use normal browser tab as an user and incognito mode an attacker to reduce time.
If the identifier value is hashed, you can use several decoding techniques to bypass it.
IDOR Types
There are various Idor types depending on how they are exploited and the basic nature of the operation.
This type of IDOR attack involves gathering information from other users by modifying the value of input fields. Attackers change URL parameters on the client-side. URL tampering attacks target the GET and POST parameters because they are susceptible to contamination of URL parameters.
2. Manipulating JSON IDs
JSON is a widely used format for data exchange between hosts. An attacker may intercept JSON data sent between APIs, servers, and web applications. If the Jason data provides the predictable values sent between APIs, servers and web application, alteration of such data cause a direct call to server resources as there are no temporary replacements for server resources in case of the exploitable application. Thus, opening the door for Idor. Jason ID example
{
"userId":527054,
"name":"Kane Root",
"email":user@securityboat.net,
"wallet":6578,
"Discount":0,
"Sales":1048
} 3. Mass Assignment and Obtaining unauthorized data access
Applying an Idor attacker may access data on a larger scale, for example getting sensitive information about every user. An attack is performed when an attacker is granted access to an internal object reference and can change the basic details of application data. Actions such as storing crucial details on the user’s database or taking control over user information fall under this attack. The IDOR attack type involves controlling user credentials such as API keys, commands, and user ID parameters so the attacker can operate illegally in the targeted application.
4. Allowing file access
This IDOR type interacts with path traversal and permits an attacker to do easy file resource manipulation. Attackers can walk through numerous sensitive files by just replacing the file name. The URL
https://vulnrable-website.com/view/1174.pdf Contains direct Reference to the object mapped internally. In the case of decryptable hash value or predictable sequence, path traversal with idor can be applied.
5. Blind Idor
Server response does not return the details or validation of the exploitation by the attacker, but the attack impacts the victim. In this case you will not be able to confirm the success of IDOR through HTTP response. The usual validation does not take place in the blind idor scenario instead information can be fetched from emails, export files or text alerts.
So, this is how Idors can be distinguished from one another depending upon the server response and the overall impact of the attack.
Idor Attack Scenarios and bypassing techniques
The testing of Idor is done at the instances where the user is commanding a database or accessing files to fetch resources or perform related actions. Examples include
In many instances, user records are altered or created by web application using parameters which unquietly identifies these account generating requests and if this parameter applies sequencing or numbering them it is easier to access other accounts as well. The user is trying to fetch a record
https://vulnrable-website.com/customer?num=cid12The user input can retrieve records from other users by changing the “num” parameter.
2. Parameter Fetching File Resources
When critical resources are stored in static files on the server-side filesystem, IDOR vulnerabilities are common. A site uses
https://vulnrable-website.com/customer?id=cid01.txtthat is used to fetch a file within the database. The user input is directly taken to fetch the file within the system. Similarly, by changing the file name, as it is a number, to retrieve credentials and other sensitive data.
3. Parameter performing an operation
In these cases, the operations related to a particular user are carried out through the input parameter and request body which can be delete, update, create, etc. The example,
https://vulnrable-website.com/customer/update?num=cid12, shows that we can perform update action related to any user.
4.Placing ids to requests without ids
Even if the request URL does not use input parameters, place parameters to each request and observe whether it makes any difference. For example, if this request displays all your card details:
GET /api/card What will happen if the attacker appends the user id as mentioned below?
GET /api/card?custom_id=<victim_id>Even if web applications sometime hide information related to parameters, by observing the adjacent requests, you can add ids randomly.
5. Parameter Pollution
By supplying multiple values for a single parameter, one may create a scenario where idor can be exploited. Change request from
GET /api/card?custom_id=<attacker_id> to
GET /api/card?custom_id=<attacker_id>&custom_id=<admin_id> or
GET /api/card?user_id=<admin_id>&custom_id=<attacker_id> 6. Replacing keywords with Reference ids
Consider a scenario where the web application uses keywords such as “user/self/customer” and uses reference_id occasionally based on the request that is being made, simply replace the keyword with reference_ids . For example, replace
GET /profile/update/user/ or
GET /profile/update/self/ with
GET /profile/update/14456/7. Appending special characters and random strings
Simply replacing ids might get you a 401, access denied or invalid request. So, in this case appending special characters (/) or strings such as %20, %1e, etc. might give you an Idor. Turn request from
GET /profile/update/14456/ to
GET /profile/update/14455%1cThis may break the application’s logic.
8. Replacing methods and Content type
Changing methods may allow you to conduct Idor validation as you should interchange methods GET, POST, PATCH, OPTIONS and DELETE if either of them fails. In most cases, just changing or replacing the ids is not enough, you must keep changing request methods in order to bypass prevention techniques.
Change request from
POST /2/account/Accounts/1234 HTTP/1.1
Host: www.securityboat.net
[…]
Content-Length: 36
Cookie:
Connection: close
email=user-name@gmail.comTo
PUT /2/account/Accounts/1233 HTTP/1.1
Host: www.securityboat.net
[…]
Content-Length: 36
Cookie:
Connection: close
email=user-name@gmail.com Modifying request file type can also be helpful in finding Idors. Altering file type at the end of URL is an example of such case. For example, changing the file name to. Json at the end of the URL or header.
Original Request
POST /api/contact/allow/435
[…]
Content-type: application/xml
<account>test</account> Modified Request
POST /api/contact/allow/123
[…]
Content-type: application/json
{“account”: “test”} 9. Encoded and hashed values
Most web applications use known encoding schemas which allow attackers to decode them easily. In instances where the id is randomized or encoded, you can check whether it is predictable. Try creating multiple accounts as it will allow you to understand the id randomization. Api endpoints sometimes leak the hashed ids in other user requests.
user=test
account_id=7541A92F-0101-4D1E-BBB0-EB5032FE1686
profile_id=MyProfile to
user=test
account_id= 5678
profile_id=MyProfile These are some cool tricks which will guide you in getting an Idor.
Best Way of Finding Idor
To automate the process of finding Idor, Firefox Multi-Account Containers
And Burp extension Authorize are used, let us see how to use them.
Multi-account container
This add-on lets you create multiple accounts in a single window.
Finding Idor certainly becomes easier with this technique.
Moving on to the Authorize,
Authorize
This burp extension allows you to repeat each request just by replacing cookies from one user to another, reducing the time consumption in manual work and helping the penetration tester detect authorization vulnerabilities.
Extender>>Options section.
Extender>>Extensions
That is, you need to surf all possible account actions to test every functionality in the web application.
6. Authorize will reply in three ways
a. Bypassed! – Red colour
b. Enforced! – Green colour
c. Is enforced? (Check it manually) – Yellow colour
Thus, Authorize + multi-account container can give you easy Idor.
Implications of Idor
Critical functionalities, if vulnerable to idor lead to severe impact, it totally depends upon the functionality which is being exploited. Some major impacts of idor are mentioned below. The highest impact is inevitable if the functionalities such as account recovery, password reset, password change and changing security questions are affected by this type of vulnerability. If the application only allows reading permissions, then also by exposing sensitive information on the client side.
Exposed object references and client-side responses may reveal sensitive information, which can be used to build injection payloads, leading to further exploitation. Server-side files are used in the usual operational process and referred through reference id. By modifying the file name, you can surf through various server files, allowing static file access.
Sometimes, you will find idor functionalities such as storing comments on the victim’s account. Such action itself is not impactful, but if combined with self XSS, which will be sent to the victim as stored XSS leads to a major impact. Modifying confidential data to get horizontal and vertical privilege escalation will allow action beyond the scope of the attacker account and bundle information onto client-side responses.
Preventions
We have covered the detection and exploitation part of Idor. Now it’s time to cover some useful prevention techniques to avoid Idors in your web application.
Use an Indirect Reference Map
The first approach is to replace all the direct object references, such as user ids, keys, names, etc., with indirect object references, which will be mapped directly to the rest of the internal objects. These client-side indirect ids can be mapped internally to direct objects present on the server side after the temporary substitution.
Implement Access Control
Servers refrain from validating resource sharing when attackers tamper with the URL on the client side. This happens as there are no access control checks applied on the server or there is no process of validating if the user has or should be granted access to a particular resource or information.
Unpredictable references
Maintaining validation of parameters and using unpredictable and random variables as input reference is difficult to anticipate for an attacker, thereby reducing the risk of malicious requests being crafted by the attacker. Hashed values and encoding can be predicted by the server, not by decoding or manual guess by end-users.
Development process to avoid leaking Private references
Developers occasionally leak direct or private references, which can be observed through bundled responses at the time of execution of that request in which the private reference is exposed. Automated scanners should be avoided, and source code reviews should be preferred.
Avoid using Sequential UUID.
Sequential use of direct object references makes it simple for an attacker to predict and scrap through all resources without difficulty. Creating substituted random values, encoded and hashed, reduces the impact caused by insecure object references.
Thus, the above-mentioned prevention techniques narrow the scope of the attack and reduce the major impact of the insecure direct object reference. Also, visit https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.md to get more prevention techniques.
Conclusion:
In conclusion, Idor is one of the most found vulnerabilities in web applications, and the simple reason is that automated tools lack in detecting Idor. Manual Testing is essential for detecting Idor comprehensively. Even if some tool detects it, it must be inspected to validate. Privilege escalation, both vertical and horizontal, comes into the picture in the case of Idor. Using multiple accounts enhances the possibility of finding Idor. The more you observe, the more you get close to finding Idors. Replacing one user id with another is not the only way to find Idor; replacing methods, file types and appending strings to break the logic of web applications must be validated. Attaching Idor with different vulnerabilities, such as account takeover and privilege escalation, can result in catastrophic damage to an organization. But you can avoid all this if preventions are considered, like using indirect object references and maintaining strong access control. Thus, Idors are a catastrophic vulnerability that affects the confidentiality of a web application which can be avoided by access control checks, session management and substituted indirect references.
Get some practice resources from Portswigger.
Here are some references:
2. How To find Idor by Bugcrowd
3. Insecure Direct Object Reference by Intigrity
6. Understanding IDOR by Appknox
Also read our previous blog here!!!
