Insecure Direct Object Reference
Insecure Direct Object Reference (IDOR) is a vulnerability where user-controlled parameters can be used to expose the format or pattern of an element or gain access to resources that are being stored in the backend code.
Attack Vector
There are a couple ways to do this attack:
Reference to objects in database:
- Retrieving information from the back-end by changing parameters/variables in a URL if no other access controls are in place
Reference to static files:
- Retrieving filenames or folders with sensitive data/information in them by visiting a URL that does not have access controls
By doing this attack, attackers can gain access to sensitive data and resources that are not evident/apparent to the user intially.
Impact
A IDOR attack can expose data and information about users, databases, etc. that should be restricted. This gives extra information to the attacker for which they can then use to their advantage.
Attack Examples
Example 1
Consider an example:
If we have some website that passes along information through query strings of a URL and uses these parameters to display the page, that are accessible to the user, attackers can manipulate the URL and gain access to restricted data through the backend.
Let's say we have a website that holds a company's employees and
employee data and queries with the following link:
https://insecure-company-website.com/employees?employee_id=99999
In this case, let's say we are employee with id 9999. When we see this query string, we can perhaps manipulate the query string as so:
https://insecure-company-website.com/employees?employee_id=11111
With this, if there is no access control here, we have now gained
access to the data of employee 11111 .
Example 2
Consider a separate example:
If we have a website with sensitive files or folders that are located somewhere in the server and that allows users to retrieve their own files, without access control, there is potential to find a pattern or format to then access other data that does not belong to us.
Let's say we have a website that holds a company's employees and
employee data, such as an employee's contract at the link:
https://insecure-company-website.com/contracts/contract99999.pdf
In this case, let's say we are employee with id 9999. And by seeing this format of the link and filename...
We can manipulate this to:
https://insecure-company-website.com/contracts/contract11111.pdf
Without access control, we have potential to access employee 11111's file instead.
In addition: We can also do this attack by trying different common keywords that might be included in this directory, to discover a pattern/format or other sensitive data that might potentially be available to us without proper access controls.
- For example, https://insecure-company-website.com/contracts/allcontracts.pdf
Defenses
For the first example:
Use of salt and hashed data. Instead of having the direct identifier such as the variable name and value be exactly what is being used to select from a database, we can instead salt and hash the variable value and make it unidentifiable to an attacker.
For the second example:
We can do path parsing, making sure that movements across directories/files or inputs from the user are valid given the scope of their current location in the website.
Criteria for Demonstration
To demonstrate an IDOR attack, (1) provide the changes made to the URL and (2) what data you gained access to.
Other resources
https://portswigger.net/web-security/access-control/idor https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html https://en.wikipedia.org/wiki/Query_string
eli32