What is IDOR Vulnerability ?

IDOR (Insecure Direct Object Reference) is a fancy term for a type of security weakness that can let hackers get their hands on stuff they shouldn’t. Basically, when a website or application doesn’t do a good job checking what users are doing, the bad guys can sneakily change the “references” to things like files, data, or features they shouldn’t be able to see or use. This can lead to them stealing information, changing stuff they’re not supposed to, and even breaking into the system.

The Story

A Security Analyst named Usama Varikkottil managed find a bypass to get IDOR vulnerability in API with  “ ../”  , which allowed him to do takeover on approximately 2 million accounts and  awarded $2500 bounty

Usama was recently discovered two critical security vulnerabilities that could lead to full account takeovers in a productivity app with over 2 million users. He gained access to these vulnerabilities by making strange API requests, which eventually led to the highest reward from two bug bounty programs.

Upon examination of the target web application features, he found two minor security issues within seven days, but did not report them because he didn’t pose a high impact. The minor issues were: no expiration of the old password reset link after requesting a new password reset link, and response manipulation during the user account deletion process.

To exploit the second vulnerability, Usama bypassed the account deletion process by simply changing a false value to true, resulting in user account deletion without the correct password.

However, Usama  wanted to increase the impact of the vulnerabilities he found, so he began experimenting with the features related to team members or workspaces. He sought to exploit response manipulation and obtain some cool privilege escalation bugs, but there were no such requests that needed a response for validation, not even 2FA. So he began testing for IDORs on the web application.

Testing IDOR Using 2 Accounts

To test IDORs, Usama registered two user accounts with two different emails example: [email protected] for the admin and [email protected] for the attacker.

By analyzing the HTTP requests and responses, he  discovered that on creating a new user account, a default workspace automatically gets created inside the user account. He created multiple user accounts to test for IDORs, using temporary email services such as temp-mail.io or mail.tm to avoid messing up their Gmail account.

Further research, Usama try  to invited the attacker to Adimon’s workspace from Adimon’s account, which revealed a major security flaw. Each request to the target API included an auth token that was different for different users. Adimon had one auth token, and the attacker had another.

By replacing Adimon’s auth token with the attacker’s auth token, he  was able to obtain Adimon’s workspace ID and execute major functions under Adimon’s account. This revelation allowed Usama  to identify two critical vulnerabilities.

The productivity app’s Responsible Disclosure Policy offered a $2500 reward for critical security issues, which the hacker was eligible to receive due to the critical account takeover bugs that he discovered.

This goes to show that API requests can reveal critical security vulnerabilities that might go unnoticed through regular security testing.

How to Prevent IDOR (Insecure Direct Object (IDOR) ?

Preventing Insecure Direct Object Reference (IDOR) vulnerability is crucial to maintain the security of your application. Here are some steps you can take to prevent IDOR vulnerabilities:

1. Implement proper access controls: Ensure that your application performs proper validation and authorization checks before accessing or performing any actions on an object. Follow the principle of least privilege to limit access to sensitive data or functionality.
2. Use indirect object references: Instead of using direct object references, use indirect references that are harder to guess or manipulate. For example, use a random or hashed value that is not easily guessable as the object identifier instead of using a database record ID.
3. Implement Role-Based Access Control (RBAC): Use RBAC to control access to different resources based on a user’s role or privilege level. This can help ensure that users can only access the resources that they are authorized to access.
4. Perform input validation: Validate all user input and ensure that it meets the expected format and data type. This can prevent attackers from injecting malicious data into the application and manipulating the object identifier.
5. Perform regular security testing: Regularly perform security testing, including penetration testing and vulnerability scanning, to identify any potential IDOR vulnerabilities in your application. Address any vulnerabilities that are found as soon as possible.

By following these steps, you can prevent IDOR vulnerabilities and ensure the security of your application. Remember that security is an ongoing process, and you should regularly review and update your security measures to stay ahead of evolving threats.

Link to read full write up: here

Save the PDF here