This is the fourth installment in a series on Web Application Vulnerability Basics.
What Is Insecure Direct Object Reference?
Insecure Direct Object Reference, also known as IDOR, is a reference to an internal implementation object that is exposed to a user without proper access control. IDOR can lead to attackers bypassing authentication and accessing resources, accounts, and modifying some data. IDOR is often leveraged for horizontal movement, but vertical movement is also possible.
How Do IDOR-based Attacks Work?
First, an attacker will identify an insecurely implemented direct object reference. This can be any type of data including integers, strings, dates or times, GUIDs, or even request headers. The attacker must also identify the data format of the fields. Using this, the attacker will determine a range and attempt to enumerate over other objects or resources they shouldn’t have access to by modifying the IDOR vulnerable field. This only works if the web application has not implemented proper access control and will serve content without verifying the user should have access to it.
For example, a bank statement uses IDOR and does not properly implement access control. An attacker generates a bank statement through the web application and sees that the URL is bank.example.com/bank_statement?statementId=4324. The attacker correctly guesses that the statementId field is autoincremented, and verifies this by accessing the statementId of 4323, which returns the bank statement of the last person to use the application from a different user. Knowing that IDOR attacks are possible on the web application, the attacker will then use a tool or script to enumerate all bank statements that have an ID between 0 and 4324 and download them.
Mitigating IDOR-based Attacks
There are a few mitigation strategies that can prevent IDOR abuse. Implement proper access control server-side to prevent users from accessing unauthorized resources. Make sure to verify the session is for the expected user and the user has access to the data they are requesting.
Another way to mitigate IDOR based attacks is to avoid directly referencing objects when possible. Use an indirect reference map, leverage internal session management or other methods to ensure that key backend references are not exposed on the front end. Limit passing identifying parameters on requests whenever possible.
If user-exposed direct object reference is necessary, avoid sequentially assigning object identifiers that are easy to enumerate. Instead, use an unpredictable and large data field for references such as GUID or UUID that makes it hard to enumerate and exploit, even if the access control has been bypassed or is missing.
Note: An IDOR attack is extremely hard for a WAF to detect, and most are not able to identify and prevent IDOR attacks. A WAF leverages pattern matching to determine if the request is valid or malicious, and since an IDOR attack modifies data inside a valid request, the signature of the request is generally unchanged. Utilizing a WAF is generally not a good strategy for preventing IDOR abuse.
Conclusion
IDOR based attacks are easy to execute and generally don’t require a high level of skill. Utilizing proper access control and validation along with avoiding direct object reference can greatly reduce the potential for an IDOR based attack. Verify that IDOR is not an issue with your web application: utilize a web app pen test from NuHarbor.
Other Posts in the Web Application Vulnerability Basics Series:
Web App Vulnerability Basics: Path Traversal
Web App Vulnerability Basics: Cross-Site Request Forgery
Web App Vulnerability Basics: Cross-Site Scripting
