What is an IDOR vulnerability and why is important to know as a Developer.

As I dive deeper into security and research, I realize that understanding the correct terminology and tools for identifying vulnerabilities is crucial. I began by studying IDOR, a straightforward vulnerability.


What is an IDOR vulnerability?


An Insecure Direct Object Reference (or IDOR for short) vulnerability is a type of security flaw in web applications where an attacker can access or manipulate sensitive data or resources by directly referencing internal identifiers, such as database keys, filenames, and IDs, without proper authorization. In other words, the vulnerability occurs when an application fails to validate whether a user is authorized to access a particular object, and the attacker can exploit this weakness to gain unauthorized access.

There could be two reasons behind the issue - either a logical error made by the developer who didn't correctly authenticate the user or displaying the identifier while connecting to the application host through a network.


It is worth mentioning tools for Hackers that make the detailed study of each application's calls, such as Burpsuite, Netsparker, OWASP ZAP. Using tools that support the testing as they intercept all traffic proves invaluable resources when verifying end-points for vulnerabilities.


The logic behind roles, groups, and permissions can get complex when writing dynamic applications.


"We don't know what we don't know."


As developers, not knowing hurts us all. We develop standards that keep our applications secure, but it is not a single Senior developer's job. 


Especially in these AGILE times, when we are encouraged to write functional code over comprehensive documentation, standards are a MUST. 


So, part of this brief snippet of thought is to educate.



How to avoid IDOR?


To avoid writing code vulnerable to IDOR, developers can implement these practices (among others):


  • Proper Access Control: It is essential to have a robust access control system in place to ensure that only authorized users can access specific resources. To achieve this, it is recommended to implement a role-based access control mechanism and carefully validate each user's permissions before granting access to any database object.


  • Use Indirect References: Instead of internal identifiers that point directly to objects in the database, we should reference them indirectly; randomly generated tokens or encrypted values should do perfectly to map to the actual resources.

Remember that attackers are studying your application structure and end-points and their responses. Adding complexity layers to referencing assets in the database makes it harder for attackers to guess or manipulate the identifiers.


  • Whitelist Validation: When dealing with user input or requests involving object references, use whitelist/safelist validation to ensure the input adheres to an approved list of values. Validation, by default, helps prevent IDOR vulnerabilities.

 Front-to-back user input validation is a MUST.


Following these and other rules/guidelines and adopting the "Hacker" mentality, developers can reduce the risk of introducing IDORs into their applications. 

Think like a hacker to avoid having someone abuse your code.


References

Yaworski, P. (2019). Real-world bug hunting: A field guide to web hacking. No Starch Press.

Kohnfelder, Loren. (2022). Designing Secure Software : A Guide for Developers. No Starch Press.