What are Insecure Direct Object References (IDOR)?

Insecure Direct Object References (or IDOR) is a simple bug that packs a punch. When exploited, it can provide attackers with access to sensitive data or passwords or give them the ability to modify information. On HackerOne, over 200 are found and safely reported to customers every month. 

What is an IDOR?

There are several types of IDOR attacks, including:

• Body Manipulation, in which attackers modify the value of a checkbox, radio buttons, APIs, and form fields to access information from other users with ease.
• URL Tampering, in which the URL is modified at the client’s end by tweaking the parameters in the HTTP request. 
• HTTP Requests in which IDOR vulnerabilities are typically found in GET, POST, PUT, and DELETE verbs.
• Mass Assignment, where a record pattern can be abused to modify data that the user should not be able to access. While not always a result of IDOR vulnerabilities, there are many powerful examples of this being the result of it. 

In its simplest and most common form, an IDOR vulnerability arises when the only input required to access or replace content is from the user. This vulnerability submitted to Shopify by California-based hacker Rojan Rijal (a.k.a. @rijalrojan) in 2018 is the perfect example.

By observing how file attachments were labeled when sending a query to Shopify's Exchange Marketplace application, Rojan was able to replace documents by leveraging the same file name from different accounts. 

Figure 1: IDOR vulnerability reported by @rijalrojan to Shopify on the HackerOne platform.

For retail and ecommerce companies, IDOR vulnerabilities represent 15% of what organizations pay bounties for and represent the top vulnerability for programs across government (18%), medical technology (36%), and professional services (31%) industries. 

If they’re so simple, why are they so common? 

In short, IDORs can not be detected by tools alone. 

IDORs require creativity and manual security testing to identify them. They require you to understand the business context of the target application. While some scanners might detect activity, it takes a human eye to analyze, evaluate, and interpret. Understanding the deeper context is an innately human skill that machines cannot replicate. In traditional pentests, unless a pentester tests every possible parameter in every request endpoint, these vulnerabilities can go undetected. 

What are the implications of an IDOR vulnerability? 

Perhaps the most infamous IDOR vulnerability as of late is that found in alt-tech social media platform Parler. The company ordered their posts by number in the URL, a telltale sign of IDOR. If you add a sequential digit to a Parler post URL, you could access the next post on the platform indefinitely. Without authentication or access limits, an attacker could easily build a program to download every post, photo, video, and data from the entire site. While this was just public posts (not necessarily IDs used to verify accounts), geolocation data from posts was also downloaded, which could reveal GPS coordinates of users' homes.  

How can you prevent IDORs from cropping up?

“Avoiding IDOR is only possible by building a robust access control mechanism, choosing the best fit methodology for your scenario, log all access and if possible do an audit with a post authorization check,” said HackerOne hacker Manoel Abreu Netto, better known online as @manoelt.

“However, if you want to reduce the impact of an IDOR, avoid using a simple pattern to reference objects in the backend, thus not using a sequential integer value but something like uuid or even a MAC (hashed ID) with a salt per user session.

This does not eliminate the IDOR, but reduces the overall impact and the ability to enumerate objects.”

To remediate IDOR vulnerabilities, below are a few best practices. 

1. Developers should avoid displaying private object references such as keys or file names.
2. Validation of parameters should be properly implemented.
3. Verification of all the referenced objects should be checked.
4. Tokens should be generated in such a way that it can only be mapped to the user and is not public.
5. Ensure that queries are scoped to the owner of the resource. 
6. Avoid things like using UUIDs (Universally unique identifier) over Sequential IDs as UUIDs often let IDOR vulnerabilities go undetected.

For more information about reducing risk and getting started with hacker-powered security, check out our CISOs Guide to Deriving Value from Hacker-Powered Security.