Hey there! Recently, I was testing out a product review application where a found a weird behaviour in the delete functionality of the comparison list. And guess what! It lead me to IDOR.

The IDOR basics

If you already know what IDOR is, feel free to skip this section!

IDOR (Indirect Object Reference) occurs when just by manipulating a field we are allowed access to resources/data which we should not have access to.

A simple example to consider here would be: https://vulnerable.com/private?id=1 give details of information that should be just visible to me. And the same applies to all the users of vulnerable.com. If by manipulating the value of id to 2, I get the private details of some other users then it would be called a classic example of IDOR. Its as simple as that.

So now Let’s jump into the story of IDOR!

Initial recon

Consider the website to be redacted.com which features blogs around various products, allows users to give feedback on those products, enabled them to create private comparison lists comparing different products.

I started by exploring all the features available within the application. Tried lots of different things but everything was patched already!

Then I landed on create comparison list. I took a few products in the bucket and created a private comparsion list. I tried accessing this private list from a different account and it was not accessible. And I was like, alright this is not vulnerable too 🙁 Let’s move ahead!

Then I deleted the comparison list that I created earlier. Burp was running as usual. Got the POST request as:

POST comparison/567456/delete
Host: redacted.com
Connection: close
Content-Length: 275
....
....

The response was received as

HTTP/1.1 200 OK
Server: nginx
Date: Friday 2 May
Content-Type: text/html
...
...

567456 deleted

Cool! The feature is working as expected.

The IDOR

Now, I thought of changing the number to something else. I simply decremented the number in the above request by 1 (567455) and hit go. And I got the response as:

HTTP/1.1 200 OK
Server: nginx
Date: Friday 2 May
Content-Type: text/html
...
...

567455 deleted

Damn! It got deleted!! But the comparison ID didn’t belong to me. Also, I tried accessing the private comparison lists from another account which didn’t work. So what’s this then?!

Now I decremented the ID to 567454 to check exactly what were the contents of the comparison list (from a different account). To my amazement, the contents were exactly the same as that in my private comparison list (that is not accessible to anyone else). Now that is information leakage! since the list is available to everyone, even the unauthenticated users.

After tinkering around for some time, I realized that these public lists get generated after a user generates a private comparison list, the ID of which can be obtained by incrementing/ decrementing the value.

And the interesting part? Anyone can delete those publicly available lists.

If you randomly type in an ID, you might end up getting the private contents of someone else’s comparison list.

Things to note

• Private information getting leaked but the corresponding user cant be determined.
• As these lists are publicly available, the ability for users to delete these list leads to denial of availability to all the other users viewing that comparison list.

The application indeed acted weird in this whole scenario (the public comparison lists getting automatically generated on the generation of a private list) and users being able to delete the public ones. But yes, its an IDOR….

Key takeaways

• Saw an id ? Try incrementing/decrementing the value.
• When testing for IDORs, use 2 different accounts.

That’s all for this blog post! Hope you enjoyed reading this weird scenario of IDOR!

See you in the next one. Until then, happy hunting 🙂