Insecure Direct Object References (IDOR)

What are IDORs?

Insecure Direct Object References (IDOR) is a type of vulnerability in web applications that allows attackers to access data that they should not be able to access.

IDORs occur when an application does not properly validate user input. Attackers can manipulate the parameters of a request to gain access to data that they should not have access to.

IDORs can be used to access sensitive data such as financial information. It can also be used to gain access to personal data, or confidential documents.

Even worse, this level of access allows attackers to overwrite and or delete data if proper permissions exist for the attacker.

---

Exploiting IDORs

IDORs can be exploited in a variety of ways.

Attackers can manipulate the parameters of a request to access data that is normally restricted to certain users.

Attackers can also use IDORs to bypass authentication and authorization checks, allowing them to access data that they should not be able to access.

Additionally, attackers can use IDORs to modify data in the application, allowing them to change the behavior of the application or even delete data.

Here’s an example of an IDOR that I found on a website and the process I used to find it.

• There was a web application that tracked user time sheets and then generated reports
• The application had a list of users that anyone could select from. This allowed me to see meta information about the billable hours they worked and who they did the work for.
• There was also a settings page that displayed everything about the logged in employee. It also let them adjust a few of the values, such as email and username.

I noticed that when I adjusted my user’s username, and hit save, it sent everything back to the server that was displayed in the user account details screen. This included things that were read only such as salary and manager.

I captured this update request with BURP and started modifying it. Sure, enough it let me change everything. Nothing was validated server side.

I started exploring the reporting and noticed that in the section that displayed meta information about other employees, hidden in the view model data, there was employee ID.

So naturally I took the employee ID and swapped it with my request to update user settings in BURP. It resulted in me being able to overwrite everything for other employees.

---

Protecting Against IDORs

The best way to protect against IDORs is to ensure that user input is properly validated.

All user input should be checked to ensure that it is valid and that it is not being manipulated by an attacker.

Additionally, applications should use secure authentication and authorization mechanisms to ensure that only authorized users can access sensitive data. Developers should also use secure coding practices.

This includes using secure coding techniques such as input validation, output encoding, and secure session management.

OWASP develops secure coding guidance that all developers should be reading and applying in their applications.

---

Summary

In conclusion, IDORs are a serious security vulnerability that can be exploited by attackers to access sensitive data.

To protect against IDORs, developers should ensure that user input is properly validated and that secure coding practices are used. Developers should use secure authentication and authorization mechanisms to ensure that only authorized users can access sensitive data.

Some of this article was automatically generated by the Open AI platform and then modified by the author to include headers, editing, formatting and personal experience. The human author takes responsibility for everything said here as well as its accuracy