Best practices to prevent IDOR vulnerabilities

What is Insecure Direct Object Reference?

Insecure Direct Object Reference (IDOR) is a vulnerability that can lead to a cyber attack. Without the user’s permission, URL parameters or form field data are changed to provide different resources than intended.

IDORs occur in “Direct Object References”, which are web-application designs where controlled resources are identified as inputs such as:

• Database keys
• File names
• File paths
• URLs

When a direct object reference poses a security threat because of substituted inputs, it becomes an Insecure Direct Object Reference.

Attackers can exploit IDORs to secretly obtain personal and business information. Types of IDOR breaches, also called parameter tampering, include Path Traversal and Open Redirect. A key element of an IDOR vulnerability is that even though the browser is connected to a page, link, or site other than the one intended, it is extremely difficult to spot.

To prevent IDOR, it’s important to validate all parameters and ensure they conform to standards. These standards include:

• Minimum and maximum allowable length
• Allowable numeric range
• Allowable character sequences
• Whether the parameter is required to conduct specific transactions
• Whether null is allowed

IDOR Examples

IDOR is not a security threat in and of itself. However, it reveals a vulnerability in the format or pattern used for the object identifier. Depending on this format or pattern, there are varying capacities to probe access to associated objects.

Web Application Example: Investment Site

Cases of IDOR may involve an investment web application that requires authentication, like Robinhood or TD Bank. Once authenticated, users see a list of investment portfolios to review and edit.

When the user selects a portfolio, this request bases the target portfolio identifier as a URL query parameter value. The server-side application verifies the previous authentication and uses the portfolio identifier to display the portfolio data to the user.

An IDOR could occur if the URL used to submit the request to view the portfolio is changed. For instance, the “portfolioId” could be changed to a value not corresponding to the portfolio owned by the user. This is an IDOR because a user is viewing data, a portfolio now owned by them, which they did not intend to view. They intended to view their own portfolio data but was redirected because an edited request was sent through a parameter.

Spreadsheet Data Example: Access to Another’s Data Download

An IDOR could occur in an application where a user can export their data to a spreadsheet via download.  When a user opts to export their data, the application creates a file and the browser is redirected to the exported file by name. The filename used to store the exported data may be a user id followed by a number.

If an attacker were to modify the specific request to download the file, the filename may be changed to reflect a different user id to download someone else’s data. This attacker may submit many URLs until they find another user’s data download.  The hacker may also replace the original file name with an arbitrary file path to see respectives to downloads.

Parameter Tampering Example

There are various examples for parameter tampering. Let’s say a cyber criminal was presented with this URL:

http://www.yourbank.com/activity/detail?account=51846636433522240425

They could alter the account parameter to view another person’s account details.

1. Changing a hidden field parameter, like <input type=”hidden” id=”product-1″ name=”cost” value=”70.00″> r, is another common attack.
2. An attacker may build a collection of valid identifiers using a discovered format and test the IDs against the application.

For example, there could be vulnerabilities in an HR application accepting employee ID to return employee information. The format or pattern of the employee ID may be:

EMP-00000

EMP-00001

EMP-00002

…

A hacker could establish a list of valid IDs from EMP-00000 to EMP-99999.

This IDOR vulnerability requires an Access Control issue in order to be successful. Access control issues allow hackers to access the data for which they have guessed the identifier.

IDOR Prevention

IT teams can combat IDOR via the following two methodologies.

Syntactic and Logical Validation

Web-applications should validate all untrusted input received with every HTTP request. Your applications should perform “whitelist validation” on each input, verifying that the incoming value meets your applications’ expectations pertaining to:

• Minimum or maximum length
• Minimum or maximum bounds for numeric values
• Acceptable characters
• Data Types like string, date, integer, or rational
• Set membership
• Pattern such as phone number, social security, or employer ID

Using whitelist validation, also called Syntactic Validation, your applications will impose checks, such as the ones above, on each input  that must be satisfied, otherwise it is rejected. Whitelist checks merely certify the content of inputs instead of trying to decipher the meaning behind them.

Your tech teams can leverage Syntactic Validation with Logical Validation by adding checks to see if the input values make sense. Logical validation takes into account the meaning behind reference value and ensures values are consistent with design intent. For example:

• An “id” parameter may represent a customer identifier. Using logical validation, it may be checked to ensure authorized access by the user.
• An “account” parameter may represent a user’s account. Using logical validation, it may be verified that the information displayed is that of the specific user’s.

Using Indirect References

Another way to combat IDORs is to design resources such as ids, names, and keys to be replaced with cryptographically strong random values. These values will correspond to the original values, and both are housed on the server so an application cannot expose a direct reference. These indirect references provide a more complex counter-attack methodology than logical validation, making it more difficult for hackers to substitute meaningful values for references.

Therefore, indirect references are the preferred strategy concerning sensitive information like loan and social security numbers. However, indirect references also make your website performance slightly worse since they influence the design of the site.

Access Control Checks

Access control checks ensure data is provided only to authorized users. Features of access control include:

• Instance-based security competencies which specify access control lists associated with domain objects.
• Resource values in session and on submit are checked at a timed interval with stored values on the server.
• Database checks to ensure information is authentic.

How To Implement IDOR Safeguards

The IDOR designs present vulnerabilities that allow hackers to potentially access personal information via substituted resources. In order to protect against a data breach at your company it’s important to implement syntactic and logical validation, indirect references, and access control checks. These safeguards require deep knowledge of your internal server and will therefore likely need to be executed by internal employees or long-term contractors.

In order to make sure your developers has the necessary skills to keep validations, references, and checks up-to-date and secure, your technology professionals need continuous and expert training. Try some of Avatao’s practical and hands-on exercises to help safeguard against IDORs!