URLs are essential to navigating all the websites and web applications we know and love. Their basic function is to identify where resources are and how to retrieve them. While URLs are necessary for the World Wide Web to work, they can also pose a security risk if not secured properly.

In this post, we will learn:

• What IDOR is and how attackers use IDOR
• Why IDOR is dangerous
• Techniques that can fix this vulnerability

Understand IDOR

A direct object reference is when a specific record (the "object"), is referenced within an application. It usually takes the form of a unique identifier and may appear in a URL.

For instance, you might notice something like "?id=12345" at the end of a URL. The number, 12345, is a reference to a specific record. Security vulnerabilities creep in when access control is not present for individual records. This allows users to access records and data they shouldn't see. This is an attack that requires a relatively low skill level.

In this instance, let's say an attacker changes the ID in the URL to 12344. In an application that is vulnerable to IDOR, the attacker would be able to see the data pertaining to that record.

How much damage can this type of vulnerability really cause?

Know Why IDOR is Dangerous

When developers are not careful, they can design a system that displays and leaks application records in various places. A breach of this magnitude can be significant, especially when sensitive data or PII are involved.

The Australian Tax Office set up a website to help businesses collect a new tax. Unfortunately, it came packaged with the unwanted feature of an IDOR vulnerability. An inquisitive user realized that the URLs within the site contained his Australian Business Number, or ABN. It just so happens that this is an easily discoverable number for any registered business. This user decided to put the numbers of other companies into the URL. He was gifted with their bank account information and personal details!

Apple recently fell victim to an IDOR vulnerability. When the iPad was first released, 114,000 customer email addresses were leaked. (To be fair, it was more a mistake on AT&T's part).

You see, AT&T built a service to support 3G connectivity for iPads. The iPad sent an identifier stored on the SIM card to AT&T's service. The service then returned the user's email address.

Unfortunately, these identifiers were simply sequential integers and thus were easily guessable. Attackers iterated through the identifiers and stole the email addresses.

Another mistake was that AT&T's service tried to "secure" the service by only returning the email address if the request's user-agent header indicated that it came from an iPad. The user-agent is only a string value that can be easily manipulated.

IDOR vulnerabilities can be subtle and sneaky. Let's discuss how to defeat them.

Defeating IDOR

Access control is the key to solving IDOR. When a user requests a specific record, make sure they are authorized to view the requested record.

Using centralized authorization modules is the best way to do this. Tools such as Spring Security provide robust and customizable authentication and authorization for applications.

Bottom line: have one module that all other code relies upon to perform authorization checks.

Another common mitigation is the use of surrogate references. Instead of using the actual database record identifiers in your URLs, you can create random numbers that map back to the actual records.

Using surrogate references ensures that an attacker cannot get to a record just by guessing the next valid identifier.

And finally, don't rely on anything that the user can manipulate to provide authorization. AT&T tried to use the user-agent header to authorize their service. Don't rely on HTTP headers, cookies, or GET and POST parameters.

With these mitigations in place, IDOR will be a thing of the past.

Secure Your References

Insecure Direct Object References are one of the easiest vulnerabilities to exploit. Don't let them sneak up on you when you least expect it. Always check that users are authorized. Don't use real database identifiers. Don't depend on user-controlled data for authorization.

Build your mastery by checking out our Learning Resources. By practicing how to mitigate IDOR vulnerabilities in the language of your choice, you'll have no problem finding and fixing this problem in your production codebases. You can also put your newfound defensive knowledge to the test with a free demo of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.

Ready to defend against IDOR attacks right now? Head to the platform and challenge yourself for free: [Start Here]