Teach your dev team how to avoid IDOR vulnerabilities
On the Avatao platform your developers will experience real-world IDOR vulnerabilities from both the attackers’ and developers’ perspectives. Your team will learn about the root cause of these issues through practical coding tutorials & challenges. Avatao’s 20+ interactive IDOR exercises will improve your developers’ security awareness and help them avoid introducing insecure direct object reference bugs in your application, even before writing their first line of code!
What are Insecure Direct Object References?
IDOR happens when an application does not perform proper validation of the user’s permissions before acting on the data referenced by the user.
Directly referencing objects (an object can be any data) happens extremely often in modern web applications. Most of the API requests nowadays include specific identifiers (user ID, resource ID, file name, etc.) which the backend acts-on, and/or returns the object to the requesting user.
This “direct object reference” becomes insecure if the application does not check the requesting user’s permissions, and just blindly returns any requested user ID’s address. This might happen if for example the API is also used by an admin panel, where admin users can see the addresses of any user. Of course, users should only have access to their own address, but if developers forget to add this permission check to the API’s code, they introduce an IDOR vulnerability.
Why do IDOR vulnerabilities occur?
- Today’s applications are becoming increasingly complex and new code gets pushed to production all the time. Most of the applications out there do not have a robust security system/framework under the hood to take the responsibility of authorization off developers’ shoulders.
- Due to this lack of a unified system, developers are forced to manually write authorization checks for every single endpoint. As the complexity increases, mistakes are prone to slip in. Unfortunately, even one missing line of authorization check from one single endpoint could introduce a serious insecure direct object reference vulnerability.
- Even with the best frameworks and systems assisting developers, misconfiguration and framework level issues could arise. Being aware of the risks & deeply understanding your environment is the foundation of securing your application from these types of vulnerabilities.
What are the consequences of IDOR vulnerabilities?
An IDOR vulnerability can have a critical impact on your application’s security. An attacker exploiting an IDOR vulnerability could access data they have no permission to. Usually, there are two different scenarios when exploiting an Insecure Direct Object Reference bug:
The IDs are incremental
If the identifiers of the resources are incremental (for example users have IDs of 11, 12, 13, 14…) the attacker can potentially leak all of the resources of the application by starting from a known ID and automatically incrementing or requesting the resources one by one.
This type of IDOR has the biggest security impact on your application.
The IDs are randomized
If the resource identifiers are randomly generated or e.g. UUID-s, the attacker has a much more difficult job exploiting the Insecure Direct Object Reference. In this case, since the attacker can’t guess the different IDs in the application, he/she can either use the IDOR to steal the data of a targeted user who the attacker knows the ID of, or the attacker has to look for a different bug/feature in the application that leaks the IDs/UUIDs of the resources.
Real-life examples of IDOR vulnerabilities
- An Instagram IDOR allowing an attacker to access anyone’s private, archived posts, or stories for a bug bounty of $30,000 – Learn more
- An IDOR in YouTube allowing an attacker to leak all of the frames from a private YouTube video for a bug bounty of $5,000 – Learn more
- A Facebook IDOR which could be exploited to create an invisible post on any Facebook page for a bug bounty of $30,000 – Learn more