Identifying and resolving vulnerabilities in your web-based application security is vital to the smooth running of your website. In this series on security, we discuss Insecure Direct Object Reference (IDOR) to shed light on website application vulnerabilities that enable unauthorized access.
Understanding IDOR Vulnerability
A Direct Object Reference is a web application design method in which entity names are used to identify application-controlled resources that are passed in URLs or request parameters.
Insecure Direct Object Reference represents a vulnerable Direct Object Reference. It involves replacing the entity name with a different value without the user’s authorization. As a result, users will be directed to links, pages, or sites other than the ones they intended to visit, without having the slightest clue about it.
IDOR may not be a direct security threat, but it creates a conducive environment for hackers to access unauthorized data.
In Action: IDOR
Websites save credit card information to make the recurring payment process easier for users. Let’s say a hacker acquires information by requesting a server to retrieve credit card information by sending the user ID value ‘10’. The user ID value is then manipulated to ‘12’ and the hacker gets the credit card information of the original user with ID value ‘12’. The server fails to verify the user request, sending the response for any value.
Generally, IDOR attacks are of two types:
- Body Manipulation. Attackers modify the value of a checkbox, radio buttons, and form fields. This lets them access information from other users with ease.
- URL Tampering. The URL is modified at the client’s end by tweaking the parameters in the HTTP request. HTTP verbs GET and POST are typically vulnerable to a URL tampering IDOR attack.
Watch this video to learn more about how IDOR works:
Preventing IDOR Vulnerability
Your website may be vulnerable to future attacks if IDOR threat actors remain present in your web applications. Here are ways to avoid IDOR vulnerability:
Use an Indirect Reference Map
An Indirect Reference Map is an alternative design method to ‘Direct Object Reference’ that helps businesses avoid IDOR vulnerabilities. It replaces the actual references (such as user IDs, names, keys, etc.) with alternate IDs that map to the original values. The mapping between the alternate IDs and actual references are maintained safely on the servers.
Let’s go back to the credit card example. Instead of using direct references in the URL www.example.com/credit/profile/id#12, use indirect references www.example.com/c/ab. Then, refer to the indirect reference map to look for the actual reference. This way, direct references containing users’ credit card information will not be exposed.
Validate User Access
Servers fail to identify tampered URLs because there are no access checks in place at the data-object level. Data layer access controls should be enforced only when the server verifies whether the current user owns or has access permissions to the requested data.
At the very least, the application should perform a Syntactic Validation to verify suspicious inputs. The application should establish criteria for incoming input, and if it doesn’t meet expectations, reject the value.
Here are some criteria you can apply to your application:
- Minimum or maximum length
- Minimum or maximum bounds (for numeric values)
- Acceptable characters
- Data Type (e.g. string, date, integer, rational, etc.)
But what do you when an IDOR attack leads to a successful data breach?
The preventive measures mentioned above can only prevent an IDOR attack from happening, but they can’t mitigate the impact of a successful attack. Your business needs to be ready for any cyberattack situation, and that includes having an action plan post an IDOR attack.