IDOR & UUIDs for PII Leakage

16:10
08.05.2025
Adm1ngmz
10

Hello, today I will share with you another report. The vulnerability we will discuss is IDOR. Using it, I was able to expose personally identifiable information (PII for short). I'll quickly explain what IDOR and PII are.

Introduction

Hello, today I will share another report with you. The vulnerability we will discuss is IDOR. With its help, I was able to expose personally identifiable information (PII for short). I'll quickly explain what IDOR and PII are.

What is IDOR

This stands for Insecure Direct Object Reference. What does this mean? Simply put, it's a vulnerability that allows an attacker to perform CRUD operations (create, read, update, delete) on behalf of other users, because the application does not check whether the user accessing the resource is actually its owner.

What is PII

This is any personally identifiable information that a user may possess and that can be used to create a copy of a specific person's profile (including emails, phone numbers, social security numbers, and so on).

Now let's get to the point

Let's call our target target.com. It's a household services provider that acts as an intermediary between workers and clients. Now that you have some context, let's talk about the vulnerability.

First, I created an account on target.com, explored all possible features, and got a good understanding of the site's logic. I started testing and placed an order on the site as a regular user, then tried to view the order information I had provided. The client was sending a request to https://target.com/api/order/123e4567-e89b-12d3-a456-426655440000 (the UUID used is an example), and in the response, I found information about my order.

Read also:

Replacement of Langchain: How OpenAI Agents SDK Handles Deep Search?

IDOR (Insecure Direct Object References) in the context of personally identifiable information (PII) leakage and UUIDs.

I thought this endpoint might be vulnerable to IDOR, but I couldn't guess other users' UUIDs to check. So I created another account, placed an order, took the order UUID, and checked it through the first account. And to my surprise, it worked! That's great, but wouldn't it be better if I found a way to get UUIDs of orders from other users. So I checked other endpoints at target.com to see if I could obtain a UUID. After some time, a promising notification popped up on the site: "The worker sent me an offer regarding my order", and along with the offer came some reviews of his past orders. The API call that returned the review IDs was https://target.com/api/profile/3166044/reviews.

The IDOR vulnerability allows an attacker to access data they shouldn't have access to by manipulating object identifiers such as UUID. This can lead to leakage of personal data such as name, address, or phone number.

After that, I discovered another endpoint that returns the review text, which contains the rating given to the worker and comments. But there was something even more significant — the order UUIDs. The endpoint returns the UUID of the order for which the review was left.

Using UUIDs (Universal Unique Identifiers) to ensure data uniqueness can help avoid collisions and simplify object management in the system. However, improper implementation of these identifiers can make the system vulnerable to IDOR attacks, resulting in leakage of personal information.

Putting all this together, I was able to gather information about other clients' orders, which included their (phone number, name, address).

The severity of the bug was high. Impact: potential disclosure of confidential client information (phone number, name, address). But unfortunately, the bug turned out to be a duplicate :’(