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.
Source: eccouncil.org
Posts
0 comments:
Post a Comment