IDOR vulnerabilities can be critical, so it’s important to understand how to protect your web application from them. IDOR vulnerabilities occur when user input is not properly validated and filtered, allowing an attacker to execute commands that would normally be restricted.
This can allow the attacker to gain access to sensitive information or perform actions that could have a negative impact on the application. IDOR vulnerabilities can be difficult to spot, so it’s important to perform regular security audits of your web application to ensure that they are protected.
IDOR vulnerabilities can be fixed by properly validating and filtering user input, so it’s important to make sure that your development team is aware of the risk and takes steps to mitigate it.
Here are some of the latest news and developments related to IDOR (Insecure Direct Object Reference) vulnerabilities:
- In June 2024, a joint advisory from CISA, ACSC, and NSA alerted vendors, designers, and web application developers about the widespread issue of IDOR (Insecure Direct Object References) vulnerabilities. The advisory emphasized the importance of adopting secure-by-design principles and conducting thorough authentication and authorization checks for every request. (Source)
- A significant IDOR vulnerability (CVE-2024-2472) was identified in the LatePoint plugin for WordPress, affecting versions up to 4.9.9. This flaw allowed attackers to manipulate session cookies, gaining unauthorized access to sensitive user information such as names, dates of birth, phone numbers, and credit card details. The issue was resolved in version 4.9.9.1.(Source)
- Security researchers Gharib Sharifi and Joel Aviad Ossi worked together to highlight the serious implications of the LatePoint plugin’s IDOR vulnerability, illustrating how it could facilitate the exfiltration of entire databases containing sensitive data.(Source)
- The widely-used Grafana application, developed in Go, was also found to have an IDOR vulnerability (CVE-2022-21713) in its Teams API. Authenticated attackers could access unintended data, search for inaccessible teams, and view team member details when the “editors\_can\_admin” flag was enabled.(Source)
- Within the npm ecosystem, the only documented CVE report for an IDOR vulnerability was linked to Clerk’s authentication integration SDK for Next.js and Node.js applications (CVE-2024-22206).(Source)
- An examination of IDOR vulnerabilities across various programming language ecosystems revealed that PHP’s Composer had the highest number of reported IDOR issues (16), while other ecosystems like RubyGems, Erlang, Nuget, pip, and Rust reported none. This indicates that IDOR vulnerabilities are more prevalent in web applications compared to libraries.(Source)
These findings highlight the importance of implementing proper access control mechanisms, validating user input, and following secure coding practices to prevent Insecure Direct object references (IDOR) vulnerabilities in web applications and APIs.
Developers and organizations must remain vigilant and proactively address these flaws to protect sensitive user data from unauthorized access and manipulation.
What is an IDOR Vulnerability?
An insecure direct object reference (IDOR) is a type of application vulnerability that allows an attacker to execute commands based on user-generated input, usually in a URL.
A rule of thumb in application programming is “never trust user-generated input,” and IDOR is a form of vulnerability where developers do not validate and filter malicious input.
An attacker exploiting an IDOR vulnerability can perform any action on the application that would normally be performed by a legitimate user, only the action would provide the attacker with access to sensitive information or give the attacker access to account-specific functionality.
Query Strings and Database Actions from URL Input
When an attacker searches for IDOR vulnerabilities, the first step is finding sites that use query string values as input. Finding vulnerabilities can be as easy as using Google’s inurl command to find sites with specific query string values.
For example, the attacker could perform the following search in Google:
site:mysite.com inurl:password
The above search query performs a search on the site “mysite.com” and restricts results to only those pages that have “password” in the URL.
An attacker can use this search query to possibly find pages that pass the user’s password in a query string variable.
This same strategy can be used for numerous other application activities including those that send input to the application.
For example, if a site uses popular software and this software has an IDOR vulnerability, an attacker can use the inurl command to find the vulnerable URLs on your site. Developers often use common variables for specific actions such as submitting commands based on an ID variable in the URL. An attacker looking for an IDOR vulnerability would use the inurl Google search directive to find the variable “id” on your site.
Assume that you have a page that uses “id” as a query string variable. You might have a page URL that looks similar to the following:
mysite.com/sendmoney?id=3743
In this example, the attacker would assume that the page functions to send a client-side money. Suppose that the page retrieves the amount and recipient from a form, but the sender ID is the “3743” value specified in the URL.
The attacker might test the page by sending dummy data to the application until the results are figured out. If the “3743” value is a user ID stored in the database, then an attacker might iterate through several numeric values to find out which user IDs are valid.
In this attack scenario, an attacker could affect thousands of user accounts stored in the application.
When the value in the URL variable links directly with database IDs, an attacker can use a URL to perform actions. If the developer does not have any validation coded into the web application page, then the attacker can trigger these actions on behalf of other users.
In the example of sending money to users, an attacker could send money to a bank account on behalf of the targeted victim.
Direct Links to Files
IDORs can be from more than just query string variables. They can also create a situation where attackers can access files. For example, suppose that you have the following URL:
mysite.com/viewdocument?id=3743The URL might then redirect to a file named:
mysite.com/viewdocument/mypdf_3743.pdf
In this example, the PDF is automatically created and stored in the “viewdocument” directory. If the web application has no authentication and authorization validation, the file would be open to the public, including a malicious user.
Even with authentication, developers must use authorization rules to block authenticated users from accessing files that they should not be able to access. Unauthorized access to files is still a vulnerability, but blocking unauthenticated users adds some protection to the file from public access.
The risk associated with this vulnerability depends on the contents contained in the file and the authorization validation in the application.
If no authorization is needed to open the file with a link to the URL and it contains personally identifiable information (PII), the vulnerability could lead to a large data breach and cost millions in litigation, reparations, incident response, and remediation.
Protecting Your Web Application from IDOR Vulnerabilities
There are a few things that you can do as a developer to prevent IDOR vulnerabilities in your web applications.
Filter input:
One of the best ways to protect against IDOR vulnerabilities is to filter all user input before it reaches the database or application. This includes both malicious input and data entered by mistake.
In PHP, you can use the filter_var function to help you with this.
Use strong authentication and authorization:
Developers should use strong authentication and authorization mechanisms in their web applications. This includes using unique user IDs, password hashing, and cryptographic methods such as two-factor authentication.
Validate input:
All user input should be validated before it is used in the application. This includes checking data types, ranges, lengths, and formats.
Escaping output:
When displaying data to users, you should escape all user-generated input. This helps to prevent against cross-site scripting (XSS) attacks.
Use HTTPS:
HTTPS provides a layer of security that can help to protect against IDOR vulnerabilities and way helpful than HTTP requests.
Keep applications and databases up to date:
Make sure that you are using the latest versions of all applications and databases, as many of these include security enhancements that can help to protect against IDOR vulnerabilities.
Perform regular security testing:
Regularly test your application for IDOR vulnerabilities using both automated and manual methods. This will help you to find and fix any IDOR vulnerabilities before they can be exploited by attackers.
Educate employees:
Make sure that all employees are aware of IDOR vulnerabilities and how they can be exploited. Employees should also know what to do if they suspect that an IDOR vulnerability has been exploited in your organization.
IDOR vulnerabilities are a serious threat to web applications. By following the best practices above, you can help to protect your application from IDOR attacks.
Bug Bounty Programs:
You can also launch Bug Bounty programs on your website to give rewards to ethical hackers for every bug they find in your web application.
There are many bug bounty programs already running out there like the famous pornhub bug bounty program which pay a huge amount every time.
Cyber Security Services:
You can also hire cyber security services like burp suite for example to check and analyse your website like database records, reference objects, reference maps, access resources, user session, access control vulnerability, posts IDs and other other authorization checks.
The next step towards protecting your web application is to use cryptographically secure IDs in query string variables.
Most programming languages have cryptographic functions that will create a new value with high entropy. High-entropy ID generation will stop attackers from determining the next value in a sequence.
In the example URL using the “3743” value, an attacker will see what happens when a value of “3744” value is used. A cryptographically secure number generator will create a value that cannot be guessed in a sequence, and an attacker would not be able to detect a pattern.
It’s also important to note that developers should not create their own custom number generator, as this introduces a low-entropy vulnerability.
The next step is to ensure that any actions performed from URL variables are properly validated. Query string values should be considered user input, and user input should never be trusted.
Validation controls should be put into place to ensure that input is not malicious. In the file access example, the application should verify that the user is authorized to view the file.
This can be done by verifying that the user has an access token, and the user has the right authorization to access the file.
Authorization is important because you might need to give other users access to files. For example, an administrator or doctor might need access to a file submitted by a patient.
Frequently Asked Questions (FAQs)
We have researched and tried to answer the following frequently asked questions;
How can IDOR vulnerabilities be detected?
IDOR vulnerabilities can be detected through manual code reviews, application security testing, and penetration testing.
What is the best way to fix an IDOR vulnerability?
The best way to fix an IDOR vulnerability is by properly validating input, using cryptographic methods to generate IDs, and verifying that the user is authorized to take the desired action.
Are IDOR vulnerabilities common?
Yes, IDOR vulnerabilities are common in web applications. They are often caused by developers not properly validating input or using predictable ID values.
What is the impact of an IDOR vulnerability?
The impact of an IDOR vulnerability can be significant. An attacker can perform any action that a legitimate user can do, including accessing sensitive information or taking control of the application.
Are IDOR vulnerabilities easy to exploit?
Yes, IDOR vulnerabilities are often easy to exploit because they allow an attacker to execute commands based on user-generated input.
No, IDOR vulnerabilities do not require special tools or skills to exploit. All that is needed is the ability to manipulate URL variables.
What do IDOR attacks look like?
IDOR attacks can take many forms, but they all involve an attacker manipulating URL variables to take any action that they should not be able to take.
Is IDOR broken access control?
No, IDOR is not a broken access control. IDOR is a vulnerability that allows an attacker to execute commands based on user-generated input.
What is the difference between broken and broken access control?
The difference between broken and broken access control is that broken access control is a security flaw that allows unauthorized users to access restricted areas of an application, while IDOR is a vulnerability that allows an attacker to execute commands based on user-generated input.
What is Owasp?
The Open Web Application Security Project (OWASP) is a nonprofit foundation that works to improve the security of software.
What is the OWASP Top 10?
The OWASP Top 10 is a list of the most common web application security risks. IDOR vulnerabilities are included in the 2017 list at number nine.
What is LFI vulnerability?
LFI stands for Local File Inclusion. It is a type of vulnerability that allows an attacker to include local files on the server.
What is RFI vulnerability?
RFI stands for Remote File Inclusion. It is a type of vulnerability that allows an attacker to include remote files on the server.
Conclusion
IDORs are critical vulnerabilities that should be fixed before an attacker finds them. Any input from a user should be considered “untrusted,” and an IDOR is a form of user input.
The values query string variables contain can be manipulated easily by anyone, so it makes these values user input that should be validated before the application performs an action based on the variable values.
To correctly protect from IDOR attacks, always validate query string values. This might be with a whitelist of allowable input, authorization, and authentication validation, and using cryptographically secure ID values in application URLs.
Any cryptographically generated numbers should only use the functions designed for creating high-entropy values so that they are not predictable.
