Zomatoooo! IDOR in Saved Payments

It’s been a while since I last posted about my findings. This time it’s the food giant Zomato. I had a sudden food craving and headed to my go-to-stop, Zomato. I browsed through the restaurants and dishes when I found something appetizing. I quickly added it to the cart and just as I was about to proceed with payment, I noticed that they presented me with some of my previously used payment methods. It scratched that part of my mind, and yes! It was time to do some intercepting. Burp Suite time guys!

I fired up my Burp Suite and started intercepting all the requests going through my phone. As I moved ahead to make the payment once again, I found a request sending a lot of parameters to fetch default_payment_options. One of those parameters was payment_method_id which seemed very interesting. Hmmm, what if I increment or decrement the payment_method_id by 1 or 2 to see if I can fetch someone else’s payment method details.

I changed the payment_method_id to a random number, and to my surprise, I could see the payment information of some random dude. What in this freaking world? Lol. I was able to see the cardholder’s name, the first 6 and last 4 digits of the card, the bank’s name, and more.

Now figuring out that the payment_method_id’s were sequential wasn’t a hard task, so it was time to do some automation. Bruteforcing Time! Hoping for no rate-limiting in place, I fired up my intruder and started to bruteforce the last 4 digits of the payment_method_id to see if I could fetch details of random people without even getting rate-limited.

It didn’t disappoint me, there was no rate-limiting and I could send as many requests as I wanted. Essentially, there was no proper check at the backend, leading to an IDOR vulnerability. I went to HackerOne, drafted a comprehensive report with a PoC video, and reported it to Zomato. They, for real, surprised me by taking just 43 minutes to reward a bounty and push a patch for the same. Godspeed guys!

Signing off.