Insecure direct object reference (IDOR) is a type of access control vulnerability in digital security. This can occur when a web application or application programming interface uses an identifier for direct access to an object in an internal database but does not check for access control or authentication.
IDOR vulnerability with direct reference to database objects
If no other controls are in place, an attacker can simply modify the customer_number value, bypassing access controls to view the records of other customers. This is an example of an IDOR vulnerability leading to horizontal privilege escalation.
Insecure Direct Object Reference (IDOR) Vulnerability Detection and Prevention
| David Tidmarsh |Web Application Hacking
When it comes to cybersecurity, the playing field is far from even. Numerous application vulnerabilities can leave a backdoor into your IT systems—and attackers often need one such vulnerability to exploit your systems to the fullest potential. Thus, organizations must continually check their web applications for IT security holes that need to be patched.
Insecure Direct Object Reference (IDOR) vulnerabilities are a common security flaw in which applications unintentionally expose sensitive internal objects such as files, databases, and user details. The Open Web Application Security Project (OWASP) has ranked IDOR vulnerabilities among the top 10 most critical web application security risks.
Any IT security expert should know IDOR vulnerabilities and how they operate. This article will cover everything you need to know about insecure direct object reference vulnerabilities: what they are, how they work, and how to prevent IDOR vulnerabilities.
What Is an Insecure Direct Object Reference (IDOR)?
An insecure direct object reference (IDOR) occurs when a web application provides users with an authorized reference or ID that can be used to access or change other unauthorized information. This is a consequence of the application only requiring a reference to access certain information instead of authenticating the user’s credentials.
One all-too-common example of insecure direct object references is user IDs. Many databases and website backends assign user IDs in ascending order, i.e., starting at one and increasing from there. This means, for example, that the account for user 8201 was created immediately before user 8202.
However, this approach can cause problems for the security of web applications. As a simple example, suppose that an application allows user 8201 to access their account settings at the following web address:
https://www.example.com/settings/user/8201
Using this information, an attacker could surmise that the account settings for user 8202 are available at the address:
https://www.example.com/settings/user/8201
By itself, this fact is perhaps not a problem. The issue with insecure direct object references occurs when the web application fails to implement proper access control. In other words, if the application does not properly validate the requesting user’s identity, an attacker would be able to view and change the account settings for other users at will.
Another extremely common occurrence of insecure direct object references is for purchases, orders, and other transactions. For example, if a user sees that their purchase ID is 19346, they might be able to view information on other purchases (e.g., 19345, 19347, etc.) simply by incrementing or decrementing this number.
Insecure direct object reference (IDOR) vulnerabilities plague businesses of all sizes and industries. In December 2021, for example, a teenage security researcher in Nepal found an IDOR vulnerability in the Facebook mobile app for Android smartphones that could expose the identities of Facebook page administrators (Arghire, 2021). In August 2022, cybersecurity research firm CyberX9 claimed that the telecom company Vodafone had exposed the call records and personal data of 226 million customers due to an IDOR vulnerability (ETTelecom, 2022).
How To Prevent Insecure Direct Object References
Randomly assigning numbers to reference objects instead of sequentially can slightly mitigate (but does not fully solve) the problem of insecure direct object references. For example, suppose all users are given a nine-digit ID number. In that case, adversaries can try a brute-force attack, testing various nine-digit numbers until they find one that refers to a valid user.
Even user ID generation methods with a high degree of randomness, such as Universally Unique Identifiers (UUIDs), are not a perfect solution for IDOR vulnerabilities. If a company’s list of user IDs is leaked, adversaries could use this list to execute attacks as long as the web application does not implement access control. Thus, organizations need a more robust approach that can stop IDOR vulnerabilities in their tracks.
The good news is that there are multiple ways to prevent IDOR vulnerabilities. Below are four options businesses can use to detect and fix insecure direct object references.
Indirect Reference Maps
With an indirect reference map, web applications replace the direct reference to an object with an indirect reference that is much more difficult to guess. For example, instead of directly using the user ID 8201 in the URL, the application could use a UUID such as:
https://www.example.com/settings/user/e194da7f-3d74-48e9-ac49-4c72e1b02eeb
Internally, an indirect reference map matches each UUID to its corresponding user ID so that the application can translate this obfuscated URL to its original form.
However, as discussed above, externally visible IDs using a high degree of randomness may be much harder to guess but not impossible. Indirect reference maps, if used, should be combined with other methods to prevent insecure direct object references.
Fuzz Testing
Fuzz testing is software testing that attempts to discover application bugs and vulnerabilities by entering random or unexpected inputs. Applications should be able to handle these strange inputs successfully without crashing or exposing unauthorized information.
Organizations can help detect (although not prevent) insecure direct object references by fuzz testing their URLs and database queries. For example, software developers at Yelp have released the fuzz-lightyear framework, which helps identify IDOR vulnerabilities in an automated manner (Loo, 2020).
Parameter Verification
The likelihood of a successful IDOR attack is decreased if the application verifies the parameters passed in by the user. Some of the checks to perform may include:
- Verifying that a string is within the minimum and maximum length required.
- Verifying that a string does not contain unacceptable characters.
- Verifying that a numeric value is within the minimum and maximum boundaries.
- Verifying that input is of the proper data type (e.g., strings, numbers, dates, etc.).
Access Validation
The most foolproof way to prevent IDOR vulnerabilities and attacks is to perform access validation. If an attacker tries to tamper with an application or database by modifying the given reference, the system should be able to shut down the request, verifying that the user does not have the proper credentials.
In particular, web applications should rely on server-side access control rather than client-side so that adversaries cannot tamper with it. The application should perform checks at multiple levels, including the data or object, to ensure no holes in the process.
How to Become a Web Application and Security Professional
Security vulnerabilities, such as insecure direct object references, are a major problem for web applications. Fortunately, through fuzz testing and access validation techniques, IT security experts can detect and prevent IDOR vulnerabilities, helping safeguard applications from attack.
Do you want to become a web application and security professional yourself, preventing insecure direct object references and other vulnerabilities? Obtaining a cybersecurity certification such as EC-Council’s Web Application Hacking & Security (W|AHS) program is an excellent career move.
EC-Council is a leading provider of IT security courses, training programs, and certifications. The WAHS certification verifies that the holder knows how to hack, test, and secure web applications from existing and emerging security threats. To learn more about how to become a web application and security professional, check out EC-Council’s page on the W|AHS certification.
References
The Open Web Application Security Project. (2013). OWASP top 10 – 2013. The ten most critical web application security risks. https://owasp.org/www-pdf-archive/OWASP_Top_10_-_2013.pdf
Arghire, I. (2021, December 21). Facebook patches vulnerability exposing page admin identity. SecurityWeek. https://www.securityweek.com/facebook-patches-vulnerability-exposing-page-admin-identity
ETTelecom. (2022, August 28). CyberX9 says data of 226 million customers of Vodafone Idea exposed to internet; telco denies claim. The Economic Times. https://telecom.economictimes.indiatimes.com/news/cyberx9-says-data-of-20-million-postpaid-customers-of-vodafone-idea-exposed-telco-denies-claim/93836994
Loo, A. (2020, January 16). Automated IDOR discovery through stateful Swagger fuzzing. https://engineeringblog.yelp.com/2020/01/automated-idor-discovery-through-stateful-swagger-fuzzing.html
Testing for Insecure Direct Object References
| ID |
|---|
| WSTG-ATHZ-04 |
Summary
Insecure Direct Object References (IDOR) occur when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability attackers can bypass authorization and access resources in the system directly, for example database records or files. Insecure Direct Object References allow attackers to bypass authorization and access resources directly by modifying the value of a parameter used to directly point to an object. Such resources can be database entries belonging to other users, files in the system, and more. This is caused by the fact that the application takes user supplied input and uses it to retrieve an object without performing sufficient authorization checks.
Test Objectives
- Identify points where object references may occur.
- Assess the access control measures and if they’re vulnerable to IDOR.
How to Test
To test for this vulnerability the tester first needs to map out all locations in the application where user input is used to reference objects directly. For example, locations where user input is used to access a database row, a file, application pages and more. Next the tester should modify the value of the parameter used to reference objects and assess whether it is possible to retrieve objects belonging to other users or otherwise bypass authorization.
The best way to test for direct object references would be by having at least two (often more) users to cover different owned objects and functions. For example two users each having access to different objects (such as purchase information, private messages, etc.), and (if relevant) users with different privileges (for example administrator users) to see whether there are direct references to application functionality. By having multiple users the tester saves valuable testing time in guessing different object names as he can attempt to access objects that belong to the other user.
Below are several typical scenarios for this vulnerability and the methods to test for each:
The Value of a Parameter Is Used Directly to Retrieve a Database Record
Sample request:
http://foo.bar/somepage?invoice=12345
In this case, the value of the invoice parameter is used as an index in an invoices table in the database. The application takes the value of this parameter and uses it in a query to the database. The application then returns the invoice information to the user.
Since the value of invoice goes directly into the query, by modifying the value of the parameter it is possible to retrieve any invoice object, regardless of the user to whom the invoice belongs. To test for this case the tester should obtain the identifier of an invoice belonging to a different test user (ensuring he is not supposed to view this information per application business logic), and then check whether it is possible to access objects without authorization.
The Value of a Parameter Is Used Directly to Perform an Operation in the System
Sample request:
http://foo.bar/changepassword?user=someuser
In this case, the value of the user parameter is used to tell the application for which user it should change the password. In many cases this step will be a part of a wizard, or a multi-step operation. In the first step the application will get a request stating for which user’s password is to be changed, and in the next step the user will provide a new password (without asking for the current one).
The user parameter is used to directly reference the object of the user for whom the password change operation will be performed. To test for this case the tester should attempt to provide a different test username than the one currently logged in, and check whether it is possible to modify the password of another user.
The Value of a Parameter Is Used Directly to Retrieve a File System Resource
Sample request:
http://foo.bar/showImage?img=img00011
In this case, the value of the file parameter is used to tell the application what file the user intends to retrieve. By providing the name or identifier of a different file (for example file=image00012.jpg) the attacker will be able to retrieve objects belonging to other users.
To test for this case, the tester should obtain a reference the user is not supposed to be able to access and attempt to access it by using it as the value of file parameter. Note: This vulnerability is often exploited in conjunction with a directory/path traversal vulnerability (see Testing for Path Traversal)
The Value of a Parameter Is Used Directly to Access Application Functionality
Sample request:
http://foo.bar/accessPage?menuitem=12
In this case, the value of the menuitem parameter is used to tell the application which menu item (and therefore which application functionality) the user is attempting to access. Assume the user is supposed to be restricted and therefore has links available only to access to menu items 1, 2 and 3. By modifying the value of menuitem parameter it is possible to bypass authorization and access additional application functionality. To test for this case the tester identifies a location where application functionality is determined by reference to a menu item, maps the values of menu items the given test user can access, and then attempts other menu items.
In the above examples the modification of a single parameter is sufficient. However, sometimes the object reference may be split between more than one parameter, and testing should be adjusted accordingly.