Insecure Direct Object Reference (IDOR) is a fairly common application vulnerability caused by misconfigured or, a complete lack of, authorization controls. IDOR vulnerabilities allow a user to view or modify other resources by changing a parameter’s value to point directly to another object that they should not have access to.
Let’s look at an example illustrated below. Suppose you are using a web application for your doctor’s office that allows you to view your lab results online. Now suppose, when looking up your own lab results, it looks something like this:
You’ll observe the user_id input parameter in the URL utilizing a simple numeric value:
I wonder what happens if we change the user_id parameter value to “1001” and reload the page.
Hmm, those aren’t my lab results. What if we went in the other direction: “999, 998, … 1.”
Oh no! The site returned the lab results belonging to another patient, and then another, and another… Congratulations, we just discovered an IDOR vulnerability!
Now imagine if a malicious actor found this. A skilled attacker could abuse this vulnerability at scale by using automated tools or a custom script to quickly harvest thousands upon thousands of records. In fact, IDOR vulnerabilities have been attributed as the cause of many high-profile data breaches both in the U.S. and around the world:
- Stalkerware Apps Leak (2021): A data leak by “stalkerware” apps transferring harvested data to servers affected by an IDOR vulnerability exposed photos, text messages, call records, and geolocation information from several hundred thousand mobile devices.
- First American Financial (2019): A data breach exposed 800 million personal financial files due to an IDOR vulnerability.
Like ice cream, IDORs come in a variety of flavors. You can have your plain vanilla ones like in our earlier example, where you have an easily guessable identifier in the URL parameter. But you can also have double chocolate chip ones like the following:
To the untrained eye, that user_id value probably looks like a bunch of random characters, so there’s no way to easily guess the user_id value for another patient, right?
Unfortunately, no. A skilled attacker or ethical hacker would quickly recognize that the user_id parameter is URL encoded, so let’s throw it into a decoder and see what we get:
Hmm… That looks pretty random, so I think we’re okay. Not so fast, remember what flavor this was (hint: double chocolate chip). That’s right. It looks like we’re using a second encoding scheme – base64. Let’s run that string through a base64 decoder and see what we get now:
You guessed it, we’ve discovered another flavor of IDOR—one that uses a weak and predictable encoding scheme (sprinkles, anyone?). All we have to do now is pick another number, base64, and URL encode the value, reload the page, and voila we’ve got another customer data sundae.
To complicate things further, IDOR vulnerable identifiers aren’t limited to just URL parameters. They can also be found in form data, JSON request data, HTTP headers, or even cookies (yum, cookies and cream, anyone?). As a result, automated vulnerability scanners have a tough time discovering them. The best way to discover these is through manual testing by a skilled penetration tester/ethical hacker using multiple accounts.
You might be asking yourself now: How do we fix this type of vulnerability? Can we just add more sprinkles? While switching to unpredictable/randomized strings for your identifiers such as Globally Unique Identifier (GUID) version 4 is good as a defense-in-depth measure, it doesn’t address the underlying cause of this vulnerability: the broken access controls.
If an attacker was able to intercept traffic to the affected application, or if they were leaked by an API vulnerable to excessive data exposure, then these complex/randomized identifiers could still be harvested and used in the same attack chain we saw earlier. The true fix for this vulnerability is to implement proper authorization control checks for each and every object a user tries to access.
Despite the potentially devastating effects these vulnerabilities can have on an organization, they are still quite common, taking the top ranking on the most recent OWASP TOP 10 List as a member of the A01:2021 – Broken Access Control category.
We routinely find this vulnerability during our Web Application, Mobile Application, and Application Programming Interface (API) penetration tests. RedLens InfoSec has a distinguished track record of helping our customers protect their sensitive data from being breached and have been awarded recent CVEs for IDOR-related vulnerabilities (more details coming to our blog soon).
Contact us for more information regarding how RedLens InfoSec can partner with you to identify vulnerabilities in your environment and strengthen your organization’s security posture.
