IDOR (Insecure Direct Object Reference)

Hello readers, today we are gonna talk about IDOR, I know most of you must be knowing what IDOR is and different ways to execute the attack. So, today we are gonna talk about another way to execute this attack which is based on the client-side restrictions and ways to bypass them. Let the hunt begin!

We will be focusing on the following pointers;

1. Debugging and exploiting client-side encryption/hashing

2. Identifying the client-side surface attack

You can read more about Debugging JS in the browser at the following link👇

https://developer.chrome.com/docs/devtools/javascript/

Insecure Direct Object Reference (called IDOR from here) occurs when an application exposes a reference to an internal implementation object. Using this way reveals the real identifier and format/pattern used of the element in the storage backend side. The most common example of it (although is not limited to this one) is a record identifier in a storage system (database, filesystem, and so on).

During a recent pentest, I stumbled upon an interesting instance where I identified that the application does not have appropriate authentication and authorization checks implemented, which can allow any malicious actor to gain unauthorized access to the arbitrary user’s data.

The Application fails to validate user’s permission and allowed to obtain arbitrary user information.

As shown in the Figure below, the application stores a ‘unique_id’ in the browser’s local storage when the user logs into the application.

Further, the stored hash value is the SHA256 hash value of the user’s email id, as shown in the Figure below.

Furthermore, it was identified that the application uses the “Hex Opcode” function to encrypt the user data whenever it tries to log into the application as shown in the Figure below.

As this was client-side encryption so there was a possibility to modify the “unique_user_id” parameter to gain unauthorized access to the arbitrary customer data.

Thereafter, I was able to access arbitrary customer information by creating a SHA256 hash value of the victim’s email.

The hash created in the above step was replaced with the original “unique_user_id” parameter as shown in the Figure below

After replacing the “unique_user_id” I was able to gain unauthorized access to the customer data as shown in the Figure below.

As shown in the Figure below, by entering hex opcode value in the console I was able to gain unauthorized access to the customer data.

Thank you All for making out the time and reading this article.

Stay Tuned for another interesting attack!!

You can connect with me @https://github.com/InfoSecAntara