IDORs (Insecure Direct Object Referencing)

What is an IDOR (Insecure Direct Object Referencing)

IDORs, (Insecure Direct Object Referencing) is a software vulneability that happens when a user who is not authorised can "directly manipulate" (Pratama and Rhusuli, 2022:1) internal object references. This allows attackers to gain unauthorised access and bypass certain access controls to access sensitive data.

Examples of IDORs include:

1. Some websites have a "user id code" (Pratama and Rhusuli, 2022:3) associated with every user account, and when accessing certain pages on a website the user id is displayed in the url bar. Attackers can easily change the id value to view data that does not belong to them.
2. Online stores may use sequential numbers as order ids, allowing for attackers to easily guess the order id of another customer which they could then use to access and steal other users order details and information.
3. Online file sharing platforms can often use predictable urls that can be modified allowing attackers to gain access to other peoples files. Its easy for the attackers to spot a pattern in the urls to help them "bypass certain access controls" (Wang, n.d:2).

The techinical details of how IDORs work

Object References: In a web application, resources such as user accounts, "files, or database records" (Demesa, E.G., 2018:1) are often represented by unique identifiers or keys. For example, a user account might be associated with an ID like "123" or a file with a reference like "file_789".

Lack of Authorization Checks: Insecure applications may fail to properly validate or enforce "authorization checks" (owasp.org, n.d.) when handling these object references. This means that even if a user doesn't have the necessary privileges, they can manipulate the object references in requests or URLs to access or modify unauthorized resources. (owasp.org, n.d.)

Sequential or Predictable Object References: In some cases, object references are generated in a "predictable manner, such as using consecutive numbers or easily guessable patterns" (KumarShrestha, A., etal, 2015:42) This simplifies the exploitation process for attackers, as they can iterate through possible object references to discover and access sensitive resources.

Direct Manipulation of Object References: Attackers can modify object references in requests sent to the application, such as changing a user ID from their own to someone else's. By tampering with these references, they can trick the application into revealing or modifying data that should be restricted. (Bhuiyan, T., 2018:10)

Unauthorized Access and Data Leakage: Once an attacker successfully exploits an IDOR vulnerability, they may gain access to sensitive data or perform unauthorized actions. For example, they could view other users' personal information, access restricted files, or modify records that they shouldn't have permission to alter.

Preventing and Mitigating the usage of IDORs

There are many different ways we can prevent or mititage the chances of an IDOR attack happening, the majority of these are simple and will increase the security of a website:

Verify User Permissions: Whenever a user attempts to access or modify a resource, ensure that the application performs appropriate "authorization" (Vithanage and Jeyamohan, 2016:221) checks to validate their privileges.

Use Indirect References: Instead of directly exposing internal object references or database keys, use "indirect references" (wiki.owasp.org n.d.) that are not easily guessable or predictable, such as using randomly generated tokens or hashes. (Avatao, 2022)

Implement Access Controls: Apply "access controls" (portswigger.net, n.d) and permissions at both the user interface and server-side components to ensure that users can only access the resources they are authorized to. (Avatao, 2022)

Perform Server-Side Validation: "Validate and verify" (Avatao, 2022) all user input on the server-side to prevent tampering and ensure that the requested resources are legitimate and authorized.

Perform Security Testing: Regularly conduct security assessments, including penetration testing and code reviews, to identify and fix IDOR vulnerabilities and other security issues. 

By following these practices, developers can reduce the risk of IDOR vulnerabilities and enhance the overall security of their applications. This can help prevent or atleast mitigate the chances of an attacker using an IDOR attack on a company. 

PORTSWIGGER LAB: User ID controlled by request parameter
*DISCLAIMER* Left click to zoom into the images for clarity

For this lab you will need to sign up to portswigger and head to the labs. For the majority of the labs you will need to use the burp suite software. I recommend doing this on a virtual machine to avoid the complexity of switiching operating systems.

The aim of this lab is to obtain the API key from the user carlos. To achieve this we are given our own account with the credentials of "wiener" and "peter". 

The first step is to log into the account that we have been given using the username of "wiener" and the password of "peter".

Once logging in and heading to the my account page we can see that our API key is given to us. It’s very bad to display the API key like that as it is can be easily accessible by attackers.

When we head over to the proxy tab on burp suite and look at the http history, we can see that the request to the my account page takes an id which is wiener, and this must be interacting with the backend of the system. If the application is not confirming the session cookie on the backend, it could be very easy for us to change the id to another user and access their my account page.

Next what we need to do is send the data to the repeater, after doing this we can see that a response is given to us which shows our username being wiener and our API key being “vNJ0Z6PKIKKnTKzZEyFlEdueMemnMWnG”

If we change the parameter id of my account to id=carlos and send it through the repeater, we can see that even without having to change the cookie it will give us Carlos’s API key of “qvnn9n4e3s0U6ctl4vsrvfYVVpjArqDm”. We know this has worked as it is a different API key compared to wieners one. We can do this without having to change the cookie because the data is not checked in the backend and it is client controllable allowing us to change the data without it being verified.

After submitting the API key to the portswigger lab, we can see that we have been successful in completing the lab.

Video on IDORs and a Portswigger lab demonstration

How does an IDOR affect the CIA Triad?

The CIA Triad is a fundemental conecpt in information security, it stands for Confidentiality, Integrity and Availability. It represents the three core principles that must be protected in a secure system.

Confidentiality: IDOR vulnerabilities can make private information vulnerable. In an IDOR attack, people who shouldn't have access to confidential data could use an IDOR attack to view or leak sensitive data. This can result in unauthorized sharing of personal information, financial records, or valuable ideas.

Integrity: IDOR vulnerabilities can mess up the accuracy and reliability of data. If attackers can change or delete things they're not supposed to, it can cause unauthorized alterations. This can lead to distorted and changed data, making it unreliable and untrustworthy. Which in turn will highly damage a companys reputation as customers are unlikely to return as they may lose trust in an orgainizations ability to provide them with real and reliable information.

Availability: While IDOR vulnerabilities primarily focus on confidentiality and integrity, they can indirectly affect the availability of a system. By exploiting an IDOR vulnerability, attackers can disrupt or block access to specific resources or functionalities. This can cause service interruptions and prevent legitimate users from accessing specific webpages on a website.

Conclusion

To summarize the blog, Insecure Direct Object References (IDORs) can create significant issues for web application developers and companies that are vulnerable to it can easily find damage worth thousands if the security vulneability is not patched. From this informative blog we have been provided with a valuable insight on why "IDORs is referenced in element A4 of the OWASP top 10" (cheatsheetseries.owasp.org, n.d.). I hope this information you learnt is going to be useful for you moving forward in the future, Thanks for reading!!  

References

Pratama, I.P.A.E. and Rhusuli, A.M. (2022). Penetration Testing on Web Application Using Insecure Direct Object References (IDOR) Method. [online] IEEE Xplore. doi:https://doi.org/10.1109/ICISS55894.2022.9915074.

Wang, H. (n.d.). Preventing Insecure Direct Object References In App Development. [online] Available at: https://www.cs.tufts.edu/comp/116/archive/fall2014/hwang.pdf

Demesa, E.G., 2018. Implementation of a Hands-on Attack and Defense Lab on Insecure Direct Object References.

KumarShrestha, A., Singh Maharjan, P. and Paudel, S., 2015. Identification and illustration of insecure direct object references and their countermeasures. International Journal of Computer Applications, 114(18), pp.39-44.

portswigger.net. (n.d.). Insecure direct object references (IDOR) | Web Security Academy. [online] Available at: https://portswigger.net/web-security/access-control/idor

Vithanage, N.M. and Jeyamohan, N. (2016). WebGuardia - an integrated penetration testing system to detect web application vulnerabilities. [online] IEEE Xplore. doi:https://doi.org/10.1109/WiSPNET.2016.7566124.

Avatao. (2022). Best practices to prevent IDOR vulnerabilities. [online] Available at: https://avatao.com/blog-best-practices-to-prevent-idor-vulnerabilities/.

owasp.org. (n.d.). WSTG - Latest | OWASP. [online] Available at: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/04-Testing_for_Insecure_Direct_Object_References

wiki.owasp.org. (n.d.). Top 10 2013-A4-Insecure Direct Object References - OWASP. [online] Available at: https://wiki.owasp.org/index.php/Top_10_2013-A4-Insecure_Direct_Object_References

Bhuiyan, T., Begum, A., Rahman, S. and Hadid, I., 2018. API vulnerabilities: current status and dependencies. International Journal of Engineering & Technology, 7(2.3), pp.9-13.

cheatsheetseries.owasp.org. (n.d.). Insecure Direct Object Reference Prevention - OWASP Cheat Sheet Series. [online] Available at: https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html#:~:text=IDOR%20is%20referenced%20in%20element