I mean, IDOR is NOT only about others ID
Hi folks! In this write-up, I’m going to talk about the vulnerability I found to broaden your perspective on IDORs.
As always, I can’t give information about the company because they run a private bug bounty program. So, let’s call them as “redacted”.
Also this will be a short write-up, but I think it will be understandable. So, let’s get started.
Foreknowledge: In redacted company, free users can create up to 3 list at the same time. If you send a request to create more than three lists, the site will give you the right to choose 3 lists and lock the 4th and other lists. Also, locked lists cannot be managed, added or removed, shared, or renamed.
Let’s analyze the normal process.
First, I submitted a request to create a list and reviewed the request I encountered.
The first thing that caught my attention was the possibility of an IDOR in the bookmark_id parameter. But I can’t see the bookmark_id value of other users and also their id values were not increasing numerically. I also tried IDOR from my 2nd account anyway. I came across 403 Forbidden.
That’s why I thought of the condition I noticed in foreknowledge. I created a list and sent it to the repeater to see the process I mentioned above. I resubmitted requests under different names and multiplied the lists. My main goal was to see if I could still check the locked lists via IDOR.
As we expected, I went back to the site and a message popped up. The site was saying I can only have three listings since I’m not premium.
So, I selected three lists and saw that the other three lists were locked automatically.
I was trying to manipulate locked list without intercepting requests, but it didn’t work. I couldn’t add an icon to the locked lists, edit its names, and share it. I only had the right to delete them.
Now it was time to go back to the bookmark_id parameter.
I selected one of the target locked lists and copied the bookmark_id value via DevTools.
I went back to the unlocked lists and chose one. I opened the Intercept and I sent a name change request.
I encountered the same request again and replaced the value of the bookmark_id with the value of the locked list I copied.
Bingo! I was able to rename the locked list. I did the same for the other alternatives. I changed the name of the locked list, added an icon. And most importantly, I was able to share it with other people even when the list was locked. The company was adding the bookmark_id value directly to the URL path to navigate to the lists. So I was able to share it with other people using the path redacted.com/lists/<<bookmarkID> even if the list was locked.
As a result, I was able to use and share it just like a regular list, even when the list was locked. My guess is that the company didn’t think they should put a separate security procedure for this feature and even though all the lists and IDs in the attack scenario were ours, IDOR did happen.
That’s all for now. Thanks for reading. See you in another write up!
You can follow me on twitter: https://twitter.com/canmustdie
From Infosec Writeups: A lot is coming up in the Infosec every day that it’s hard to keep up with. Join our weekly newsletter to get all the latest Infosec trends in the form of 5 articles, 4 Threads, 3 videos, 2 Github Repos and tools, and 1 job alert for FREE! https://weekly.infosecwriteups.com/
